Over eigenaarschap, registratieniveau en wie uiteindelijk beslist over landbouwdata
Of het nu regeneratief is, biologisch, Natura 2000-melk of akkerrand-graan, wie nadenkt over hoe landbouwdata in de keten moet stromen, komt vroeg of laat bij dezelfde vraag uit: er hoort een datamodel onder te liggen. Een plek waar gegevens samenkomen, geüniformeerd worden en gedeeld kunnen worden met klanten, ketenpartners en overheid. Een datapool, een stoffenbalans, een uitwisselingsstandaard, de naam verschilt per gremium, het beeld is steeds vergelijkbaar.
Op papier is governance vaak wel benoemd. Maar in de uitwerking, op het moment dat een leverancier wordt geselecteerd of een koppeling wordt gelegd, krijgen de drie kernvragen: 1) wie is eigenaar, 2) wie beheert, 3) wie mag ontvangen, vaak minder gewicht dan de technische vraag. Dat is precies waar het misgaat.
Wat er onder een datamodel ligt is geen techniek
Een datamodel beantwoordt drie vragen voordat er ook maar één regel code wordt geschreven:
- Wie is eigenaar van welke data?
- Wie beheert die data, in opdracht van wie?
- Wie mag welke data ontvangen, voor welk doel?
Dat zijn geen technische vragen. Het zijn vragen over eigendom, governance en vertrouwen. Wie ze niet aan de voorkant beantwoordt, krijgt ze later terug als bestuurlijk probleem: dubbele petten, oneigenlijke toegang tot concurrentiegevoelige informatie, rolvermenging tussen ketenpartijen en soms zelfs directe betrokkenheid van de overheid bij het databeheer. Op dat moment is het ontwerp al gemaakt, en is bijsturen kostbaar tot bijna onmogelijk.
In andere sectoren is dit opgelost door een onafhankelijke standaardisatiepartij aan te wijzen die het datamodel beheert namens de keten. Geen enkele ketenpartij, niet de producent, niet de verwerker, niet de retailer, en zeker niet de overheid, kan zo’n model in zijn eentje beheren zonder in een rol terecht te komen die het systeem ondergraaft.
Het registratieniveau bepaalt wat er later mogelijk is
Een tweede laag ligt nog dieper: het niveau waarop data wordt vastgelegd. In veel huidige voorstellen gebeurt dat op bedrijfsniveau. Één getal per onderneming, per jaar, per indicator. Dat lijkt praktisch, maar het is een keuze die alle latere mogelijkheden beperkt.
Een melkveehouder kan meerdere stallen hebben, in verschillende gebieden, met melk die naar verschillende klanten gaat. Bijvoorbeeld hoeveel melkveebedrijven in Nederland hebben een deel van hun grond(gebruik) in een Natura 2000-gebiedsring liggen? Hoeveel stallen staan wel in een Natura 2000-gebiedsring, maar hebben grond in gebruik buiten die ring? Wat heb je dan aan bedrijfsniveau-informatie? Wat zegt die informatie je dan?
Een andere valkuil is dat de boer zijn product(en) maar aan één afnemer verkoopt. Bij akkerbouwers is dat vaak al niet het geval, die verkopen verschillende producten via verschillende afzetkanalen. Wie een datamodel bouwt vanuit de aanname dat één producent levert aan één klant, bouwt iets dat over vijf jaar niet meer past.
Het ontwerpuitgangspunt hoort omgekeerd te zijn: data wordt vastgelegd op het laagst relevante niveau (perceel, stal, batch, dier waar nodig), en wordt vandaar uit samengevoegd naar het niveau waarop een klant of regelgever het nodig heeft. Van detail naar overzicht is altijd mogelijk. Van overzicht terug naar detail is niet mogelijk, die informatie is dan al weggegooid.
De sector spreekt zelf al decennia over precisielandbouw: maatwerk per perceel, per vierkante meter, soms per plant. Wie precisie zegt, kan zich geen registratieniveau veroorloven dat alle verschil al heeft gladgestreken.
Drie scheidingen die je vooraf moet maken
Wie nu beslist om een datamodel op te tuigen, kan drie scheidingen niet uitstellen. Later zijn ze technisch niet meer aan te brengen zonder het model opnieuw te bouwen.
Product en productieapparaat. Een klant heeft vragen over het product (waar komt deze ui vandaan, hoe is hij geteeld, wat is de footprint). Een toezichthouder heeft vragen over het productieapparaat (voldoet dit bedrijf aan de vergunningsvoorwaarden). Twee verschillende datavragen, met twee verschillende rechthebbenden. Vermeng je ze in één structuur, dan zien partijen vroeg of laat data die ze niet horen te zien.
Brondata en geleverde informatie. De brondata blijft bij de ondernemer en bij de aangewezen beheerder. Wat naar buiten gaat, is een afgeleide, bij voorkeur in de meest gecomprimeerde vorm die het doel dient. Een toezichthouder hoeft vaak alleen ja/nee. Bij beloningsregelingen vanuit een overheid volstaat een categorie (brons, zilver, goud — niet de onderliggende score). In de (product)keten is detailinzicht wel gewenst. Klanten hechten waarde (en dus beloning) aan die inzichten voor hun scope 2 en 3.
Vrijwillig en verplicht. De aantrekkingskracht van een goed datamodel is dat het ondernemers meerwaarde biedt. Die meerwaarde verdwijnt op het moment dat deelname een verplichting wordt, dan wordt het een lastenpost. Bestaande overheidsregistraties (Gecombineerde Opgave, I&R) horen daarom bij de start bewust náást de datapool te blijven bestaan. Pas als de fundering staat, kan koppeling een ondernemerskeuze worden.
Wat dit betekent voor wie nu beslist
Wie aan een bestuurstafel zit en een opdracht uitschrijft voor “een datamodel”, neemt impliciet beslissingen over eigenaarschap, registratieniveau en governance — ook als die woorden niet in de opdracht staan. Twee vragen verdienen voorrang voordat de implementatievraag opkomt:
- Welke partij is in dit ontwerp onafhankelijk genoeg om de databeheerdersrol te dragen zonder zelf belanghebbende te zijn in de informatie die er doorheen loopt?
- Welke ondergrens van registratieniveau bouwen we in, zodat het model over vijf jaar de doorsneden kan leveren die we vandaag nog niet kunnen voorzien: voor klantvragen, keurmerken, beloningsregelingen én voor doelsturing en KPI’s?
Wie nu om tafel zit bij zo’n ontwerpkeuze, of merkt dat het gesprek al richting leverancier en koppeling beweegt zonder dat eigenaarschap, registratieniveau en governance scherp zijn: stop even. Zoek het gesprek op met iemand die deze drie vragen eerst stelt. En die ze blijft stellen tijdens de bouw, want bij elke koppeling, elke nieuwe partij en elke uitbreiding van scope keren ze terug. Dat is wat ik mensen aanbied vanuit VBCA: ervoor zorgen dat het fundament klopt — en blijft kloppen.
Een datamodel is geen IT-project dat na de visievorming begint. Het is de plek waar visievorming zich vastlegt in structuur. Wie het zo behandelt, krijgt een fundament voor dertig jaar. Wie het als implementatie behandelt, krijgt een systeem dat na vijf jaar opnieuw op tafel ligt.
Voor wie hier verder over wil lezen: in de reeks Doelsturing en KPI’s van Van Buuren Continuum Advisory worden deze vraagstukken stap voor stap uitgewerkt. De volledige reeks (acht delen) staat op vanbuurencontinuumadvisory.nl/publicaties/doelsturing-kpis.
Jeroen van Buuren | Van Buuren Continuum Advisory (VBCA) — Adviseur op het snijvlak van systeemvraagstukken, landbouw en beleid.