Leestijd: 3 minuten

Klanten vragen mij vaak advies over de beste vorm van een datamodel. De spagaat waarin financiële instellingen zich bevinden, wordt gevormd door de vele uitvragen van de toezichthouders en de verscheidene businessafdelingen van het bedrijf. Oftewel: hoe maak je slim gebruik van je verantwoordingsdata voor de besturing van je organisatie?

1. Het datamodel moet de organisatie representeren

De verleiding om zo snel mogelijk de gevraagde formaten van de toezichthouder te volgen, is groot. Men denkt vaak: het scheelt een stap of: het is alleen maar voor de toezichthouder. Maar hoe ga je dan sturen op de kpi’s zoals ze gevraagd worden door de toezichthouder, zoals LCR, NSFR, Leverage ratio?

Analisten willen graag de getallen verklaren en bespreken met belanghebbenden, maar hoe vertaal je rijen en kolommen, of nog erger: coördinaten in de XBRL-taxonomie van de rapportages naar items waar de business dagelijks mee werkt en invloed op kan uitoefenen? Wanneer je datamodel zo veel mogelijk lijkt op objecten die de business herkent, wordt het analyseren, verklaren en bespreken van kpi’s veel makkelijker.

2. Houd het model simpel

Datamodellen lenen zich bij uitstek voor normalisatie, waar data-architecten terecht dol op zijn. De modelstructuur van een onderhandse lening of een callgeld-deal verschillen in feite nauwelijks. Je slaat alleen andere modaliteiten op van deze twee typen leningen. Zeker wanneer je (business)analisten toegang geeft tot je datamodel, werken zij veel makkelijker en overzichtelijker met de data als bijvoorbeeld een RMBS in dezelfde tabel aanwezig is als een Nederlandse staatsobligatie, maar dan met andere typeringen.

3. Vermijd ambiguïteit

Zorg voor duidelijke definities en benamingen voor objecten in het datamodel, in de gehele organisatie. Zorg dat elke keer wanneer je dezelfde term gebruikt, deze ook dezelfde betekenis heeft. Wanneer het onvermijdelijk is om twee of meer definities voor een term te hanteren, dan kun je het beste een andere term gebruiken. Denk bijvoorbeeld aan naam van een product en naam van een persoon. Hier kun je beter kiezen voor bijvoorbeeld persoonsnaam en productnaam met ieder een eigen definitie. Het bijelkaar brengen van bijna gelijke definities zorgt voor minder spraakverwarring en beter vergelijkbare cijfers, vooral waar het de overlap van Finance en Risk betreft.

4. Houd data zo lang mogelijk granulair

Historisch werd data, vooral voor rapportagedoeleinden, vroeg in het proces geaggregeerd. Daardoor werd elke verklaring van de totstandkoming van de cijfers een tijdrovende klus. Met de huidige snelle opslag van data, is dit argument niet meer van toepassing. Door in het rapportageproces alle detailinformatie zo lang mogelijk beschikbaar te houden, maak je analyses veel makkelijker. Elke ad hoc-vraag van businessgebruikers, RvC, accountant of toezichthouder is dan snel te beantwoorden. Analisten kunnen beter de drijvende krachten van een kpi bepalen, om zo de business te adviseren hoe de beschikbare middelen het meest efficiënt en effectief kunnen worden ingezet.

5. Werk in architectuur

De data-architectuur kent verschillende lagen of stadia in het proces van invoer tot rapportage. Voor je datamodel is het van belang te zorgen dat elke laag of elk stadium zijn eigen functie heeft. In de invoerlaag wordt data ingevoerd. Daarna wordt deze historisch opgeslagen, verwerkt tot het businessobjectenmodel waar de hele organisatie zich in herkent en als laatste in het gewenste formaat gerapporteerd. Pas in de laatste stap wordt de data getransformeerd naar het formaat dat de afnemer wenst. Voor businessgebruikers zijn dit standaard (kpi-)rapporten en analysemogelijkheden, waar tot individuele kasstroom kan worden ingezoomd. Voor CRD IV-rapportages wordt de data omgezet naar een XBRL-formaat en voor AnaCredit en SHSG naar een csv-formaat.

Gestroomlijnd rapportageproces

Wanneer je bovenstaande tips opneemt in je way of working, zul je merken dat gesprekken tussen afdelingen onderling, maar ook met de Raad, accountant en toezichthouder veel soepeler verlopen, omdat je dezelfde taal spreekt en alle cijfers op elkaar aansluiten. Ook zijn changes sneller door te voeren en kun je altijd de totstandkoming van de cijfers verklaren.