Bepalen welke tabellen en relaties nodig zijn binnen de oplossing, zodat een solide, schaalbaar en toekomstbestendig datamodel ontstaat.
Het datamodel vormt de basis van iedere Power Platform-oplossing.
Een datamodel beschrijft:
Welke gegevens worden vastgelegd
Welke tabellen nodig zijn
Hoe gegevens met elkaar samenhangen
Wie verantwoordelijk is voor de gegevens
Hoe gegevens door processen bewegen
Een goed ontworpen datamodel:
✅ voorkomt duplicatie
✅ ondersteunt processen en rapportages
✅ vereenvoudigt integraties
✅ verhoogt datakwaliteit
✅ ondersteunt toekomstige uitbreidingen
Een slecht ontworpen datamodel leidt vaak tot complexe oplossingen, slechte prestaties, extra maatwerk en problemen bij toekomstige wijzigingen.
Tables & Relationships
↓
Fields
↓
Forms & Views
↓
Model-Driven App
↓
Gebruiker
Tables en Relationships vormen de basis van het datamodel.
Fields bepalen welke informatie wordt opgeslagen.
Forms bepalen hoe gebruikers gegevens invoeren en raadplegen.
Views bepalen hoe gegevens worden gefilterd en weergegeven.
Forms en Views worden gebruikt binnen één of meerdere Model-Driven Apps.
De Model-Driven App bepaalt hoe gebruikers met de oplossing werken.
Bepaal welke tabellen noodzakelijk zijn om het proces te ondersteunen.
☐ Belangrijke tabellen geïdentificeerd
☐ Standaardtabellen beoordeeld
☐ Maatwerktabellen beoordeeld
☐ Eigenaarschap bepaald
☐ Naamgeving vastgesteld
Een overzicht creëren van alle gegevensobjecten die nodig zijn binnen de oplossing.
✅ Account
✅ Contact
✅ Opportunity
✅ Project
✅ Contract
✅ Servicemelding
🚩 Te veel maatwerktabellen
🚩 Onduidelijke verantwoordelijkheden
🚩 Tabellen zonder duidelijke businesswaarde
🚩 Techniek leidend in plaats van procesbehoefte
Bepaal hoe gegevens met elkaar samenhangen.
☐ Relaties gedefinieerd
☐ 1:N relaties geïdentificeerd
☐ N:N relaties beoordeeld
☐ Cascadegedrag onderzocht
☐ Impact op processen vastgesteld
Zorgen dat gegevens correct gekoppeld kunnen worden en hergebruik van informatie mogelijk wordt.
✅ Account → Contact
✅ Project → Taak
✅ Klant → Contract
✅ Product → Productcategorie
🚩 Onnodige N:N relaties
🚩 Complexe afhankelijkheden
🚩 Relaties zonder businessdoel
🚩 Verlies van gegevensintegriteit
Bepaal wie verantwoordelijk is voor gegevens en hoe gegevens zich ontwikkelen.
☐ Data-eigenaar vastgesteld
☐ Lifecycle beschreven
☐ Statussen bepaald
☐ Verantwoordelijkheden vastgelegd
☐ Archivering beoordeeld
Begrijpen hoe gegevens ontstaan, wijzigen en uiteindelijk worden afgesloten of gearchiveerd.
Wie beheert deze gegevens?
Wie mag wijzigingen uitvoeren?
Wanneer wordt een record afgesloten?
Wanneer mag een record verwijderd worden?
🚩 Geen eigenaar
🚩 Onduidelijke processen
🚩 Verouderde gegevens blijven bestaan
🚩 Geen lifecyclebeheer
Beoordeel of standaardfunctionaliteit optimaal wordt benut.
☐ Standaardtabellen onderzocht
☐ Maatwerkbehoefte gevalideerd
☐ Overlap voorkomen
☐ Toekomstbestendigheid beoordeeld
Voorkomen dat maatwerk wordt gebouwd terwijl standaardfunctionaliteit beschikbaar is.
✅ Gebruik Account in plaats van Klant
✅ Gebruik Contact in plaats van Relatiepersoon
✅ Gebruik Activities voor interacties
✅ Alleen maatwerk waar noodzakelijk
🚩 Maatwerk zonder noodzaak
🚩 Functionele overlap
🚩 Moeilijk onderhoudbaar model
🚩 Hogere beheerkosten
Controleer of gegevens eenduidig kunnen worden beheerd.
☐ Dubbele gegevens voorkomen
☐ Masterdata geïdentificeerd
☐ Source of Truth bepaald
☐ Validaties onderzocht
☐ Referentiedata beoordeeld
Waarborgen dat gegevens betrouwbaar en consistent blijven.
🚩 Dubbele klantgegevens
🚩 Meerdere bronnen voor dezelfde informatie
🚩 Onduidelijke datadefinities
🚩 Geen governance op masterdata
Gebruik deze vragen tijdens workshops en interviews.
Welke informatie moet worden vastgelegd?
Welke gegevens zijn essentieel voor het proces?
Welke gegevens zijn optioneel?
Hoe hangen deze gegevens met elkaar samen?
Welke afhankelijkheden bestaan?
Wie is verantwoordelijk voor deze gegevens?
Wie mag gegevens wijzigen?
Hoe verandert data gedurende het proces?
Welke statussen bestaan?
Wanneer wordt een record afgesloten?
Bestaan deze gegevens al in andere systemen?
Wat is de primaire bron van de gegevens?
Na afronding van deze activiteit zijn beschikbaar:
Conceptueel datamodel
Overzicht van tabellen
Overzicht van relaties
Data-eigenaarschap
Lifecyclebeschrijvingen
Definitie van belangrijkste attributen
Leg alle bevindingen vast in de projectspecifieke Discovery Documentation.
De Discovery Documentation vormt de centrale bron voor:
Datamodel
Oplossingsontwerp
Architectuur
Integraties
Rapportages
Datamigratie
Zorg ervoor dat alle keuzes herleidbaar zijn naar de vastgelegde documentatie.
Visualisaties helpen stakeholders om gegevensstructuren beter te begrijpen.
Toont:
Tabellen
Relaties
Cardinaliteit
Gegevensstructuur
Visualiseren:
Datastromen
Processtappen
Afhankelijkheden
Visualiseren:
Bronsystemen
Integraties
Bestemmingssystemen
✅ Houd diagrammen eenvoudig
✅ Gebruik consistente naamgeving
✅ Valideer met stakeholders
✅ Koppel visualisaties aan de Discovery Documentation
🚩 Te veel tabellen zonder duidelijke noodzaak
🚩 Duplicatie van gegevens
🚩 Tabellen technisch in plaats van functioneel ontwerpen
🚩 Geen rekening houden met toekomstige groei
🚩 Onduidelijke eigenaarschapstructuur
🚩 Verkeerd gebruik van standaardtabellen
🚩 Geen lifecycle of archivering definiëren
Start vanuit processen, niet vanuit techniek
Gebruik standaardtabellen waar mogelijk
Beperk maatwerk tot echte businessbehoeften
Denk na over toekomstige uitbreidingen
Definieer eigenaarschap vroegtijdig
Voorkom duplicatie door een duidelijke Source of Truth vast te leggen
Na afronding van de analyse van Tables & Relationships is duidelijk:
Welke tabellen nodig zijn
Hoe gegevens met elkaar samenhangen
Wie verantwoordelijk is voor gegevensbeheer
Hoe gegevens zich ontwikkelen gedurende het proces
Welke standaardfunctionaliteit benut kan worden
Hoe duplicatie en datakwaliteitsproblemen worden voorkomen
Deze informatie vormt de basis voor Fields, Forms, Views, Integraties, Datamigratie, Rapportages en het uiteindelijke Solution Design.