Elk fysiek product begint als een idee en eindigt als een fysiek object – maar daartussen schuilt een explosie van onderdelen, data en complexiteit. Net als bij een ruitvorm begint een ontwerp bovenin eenvoudig met het benoemen van de functies van het eindproduct. Vervolgens worden de deelontwerpen gedecomponeerd, wat resulteert in duizenden onderdelen: de stuklijst, met alle componenten die moeten worden gekocht of gemaakt. Tijdens de assemblage worden al deze onderdelen samengebouwd en ontstaat daaruit uiteindelijk het gewenste éne eindproduct.

Dit spanningsveld tussen decompositie en herassemblage zien we niet alleen in productontwikkeling, maar ook in data-organisatie. Hoe structureer je inzichten logisch in een steeds complexere wereld? Zowel de ontwerp-explosie als de productie-implosie volgen de structuur van een zandloper én een ruit. Uit vele processen komt data ‘in het midden’ bij elkaar in een gezamenlijke repository en waaiert vervolgens weer uit naar alle specifieke gebruiks- en lifecycleprocessen van het product. Hoe deel je vervolgens die data in eigen organisatie, in je ecosysteem van partners en met alle partijen om je heen? 

Diensten zien als producten en (maak- en uitvoerings)processen

De industriële engineering- en productiewereld wordt vaak beschouwd als iets heel anders dan de diensten- en kantoorwereld. Echter, op de keper beschouwd zijn die verschillen – zeker vanuit data-oogpunt – beperkt. Diensten zoals een verzekering, een taxirit, een uitkering of een vergunning kunnen we prima beschouwen als een product dat, net als een tastbaar product, wordt ontworpen, geproduceerd en tijdens de lifecycle moet worden onderhouden. Omdat fysieke producten, zoals vliegtuigen en auto’s, al veel eerder door wetgeving aan strikte kwaliteitseisen zoals ISO- en CE-keurmerken moesten voldoen, heeft de maakindustrie eind vorige eeuw tijdens de eerste golven van digitalisering deze kwaliteit – noodgedwongen – in de processen en systemen ingebouwd.

In de dienstensector was dat anders en minder dwingend, waardoor een vorm van digitalisering ontstond waarin kwaliteit (nog) niet vanzelfsprekend was ingebouwd in de processen en systemen. Hierdoor hebben de dienstensector en de overheidssector een achterstand op het gebied van digitalisering: het denken in metadata als basis voor centraal masterdatamanagement en lifecyclemanagement. Veel diensten werden niet als product gezien, maar dat verandert met digitalisering en AI. Deze ontwikkelingen creëren de behoefte aan centrale datalakes om – data centrisch en data gedreven – met verzamelde eigen (product)data binnen de organisatie te werken. Het creëren en benutten van datalakes vereist gedegen masterdatamanagement op basis van inzicht in alle datastromen in de organisatie, van boven naar beneden en van de ene view op een proces tot een andere. De onderliggende dataproducten moeten in een m:n-relatie (vele naar vele) kunnen worden beheerd: van creator tot gebruiker, van overheidsonderdeel tot elke burger en elk bedrijf.

Gelijkwaardig en tweezijdig datadelen

In het midden moet zowel de creator een compleet overzicht hebben van al zijn gebruikers of burgers als andersom: elke gebruiker of burger moet inzicht hebben in de verschillende leveranciers van data. Daar, in het midden, komt alle informatie samen in de juiste context. Data delen gebeurt vanuit twee richtingen: de creator biedt aan, de gebruiker vraagt op. Maar die rollen kunnen wisselen – een gebruiker kan ook creator worden, en een creator kan zelf weer gebruiker zijn. In essentie draait het om een dynamisch evenwicht: data delen op een manier waarbij beide partijen samenwerken en er samen beter van worden. In feite de organisatie van een digitaal baliegesprek, zie mijn blog daarover.

Een voorbeeld: een burger heeft zowel een belastingaanslag, een bijstandsuitkering als een zorgbijdrage, en deze drie ‘overheidsproducten’ hangen onderling samen. Als de ene verandert, verandert de ander mee. Hoe kunnen zowel de overheid als de burger een volledig en actueel overzicht behouden van de samenhang tussen deze drie persoonlijke producten, zeker als deze door verschillende overheidsdiensten worden aangeleverd? En hoe kun je die samenhangende informatie op een goede manier met elkaar delen? Dit is data sharing in optima forma, waarbij zowel privacy als doelbinding een essentiële rol spelen. Deze vorm van delen is alleen mogelijk als beide partijen volledige toestemming geven voor het delen en gebruiken van die data.

Samenvattend

In een wereld waarin data steeds waardevoller wordt, moeten we kritisch kijken naar hoe we data structureren, delen en beveiligen. Data is geen bezit, maar een gedeeld goed. Wie de kracht van de ruit ende zandloper begrijpt, ziet hoe data beweegt tussen complexiteit en eenvoud, tussen creatie en gebruik. De sleutel ligt in een open en beheerste samenwerking tussen creator en gebruiker, waarbij het midden – de gedeelde waarheid – de spil vormt van effectieve dataviews. De vraag is niet óf we data moeten delen, maar hoe we dit zo organiseren dat iedereen – overheid, bedrijven én burgers – er evenwichtig van profiteert.

Photo by NASA on Unsplash

—————–   Translated by ChatGPT  —————-

Dataviews: Sharing Data Through Dual Insights

Every physical product starts as an idea and ends as a tangible object – but in between lies an explosion of data and complexity. Just like a diamond shape, a design starts at the top with a simple definition of the end product’s functions. Then, sub-designs are decomposed, resulting in thousands of individual components: the bill of materials, listing all parts that must be purchased or manufactured. During assembly, these come together into a single final product. This tension between decomposition and reassembly is not only seen in product development but also in data organization. How do you logically structure insights in an increasingly complex world? Both the explosion of design and the implosion of production follow the structure of an hourglass and a diamond shape. Data from numerous processes converges ‘in the middle’ into a shared repository and then spreads back out to all specific usage and lifecycle processes of the product.

Viewing Services as Products and (Manufacturing and Execution) Processes

The world of industrial engineering and manufacturing is often seen as vastly different from the services and office environment. However, upon closer examination, these differences – particularly from a data perspective – are quite limited. Services such as insurance, a taxi ride, social benefits, or permits can be seen as products, designed, produced, and maintained throughout their lifecycle, just like physical products. Because physical products—such as aeroplanes and cars—were subject to strict quality regulations like ISO and CE certifications much earlier due to legislation, the manufacturing industry incorporated these quality standards into its processes and systems during the first waves of digitalisation at the end of the 20th century.

In the service sector, however, digitalisation evolved differently, often without these quality standards being automatically embedded in processes and systems. This has resulted in an additional digitalisation backlog for both the service and public sectors, particularly in the adoption of metadata as a foundation for central master data management and lifecycle management. Many services were not initially considered as products, but digitalisation and AI are changing that perception. These advancements create a need for central datalakes, enabling organizations to work with their own collected data internally. Establishing and utilising datalakes requires robust master data management based on insight into all data flows within the organisation, from top to bottom and across different process views. The underlying data products must be managed in an m:n (many-to-many) relationship: from creator to user, from government entity to every citizen and company.

Equal Data Sharing

In the middle, both the creator must have a complete overview of all their users or citizens, and vice versa: each user or citizen must have insight into the various data providers. At this central point, all information converges in the proper context. Data sharing occurs from two perspectives: the creator supplies the data, while the user requests it. But these roles can shift—a user can become a creator, and a creator can also be a user. Essentially, it is about a dynamic balance: sharing data in a way that fosters collaboration and mutual benefits. In fact, it mirrors the organisation of a digital counter interaction—see my blog on this topic.

An example: A citizen receives a tax assessment, a social assistance benefit, and a healthcare contribution—three ‘government products’ that are interconnected. If one changes, the others adjust accordingly. How can both the government and the citizen maintain a complete and up-to-date overview of the relationship between these three personal products, especially when they are provided by different government agencies? And how can this interconnected information be shared effectively? This is data sharing in its purest form, where privacy and purpose limitation play a crucial role. Such sharing is only possible if both parties give full consent for the data to be shared and used.

Conclusion

In a world where data is becoming increasingly valuable, we must carefully consider how we structure, share, and secure data. Data is not private property but a shared asset. Those who understand the power of the diamond shape and hourglass structure see how data moves between complexity and simplicity, between creation and usage. The key lies in an open yet controlled collaboration between creator and user, where the middle—the shared truth—serves as the foundation for effective dataviews. The question is not whether we should share data, but how we can organize it so that governments, businesses, and citizens all benefit in a balanced way.