Self-service KPI-rapportage door metadata-gestuurd KPI-framework

Zou je graag rapportages robuuster en meer toekomstvast maken, maar heb je geen IT-afdeling met de middelen om zo’n omgeving te onderhouden? Nippur heeft een dynamisch KPI-framework ontworpen voor zorggroep PoZoB, waarmee nieuwe KPI’s door de analisten zelf kunnen worden toegevoegd.

In de opdracht door zorggroep PoZoB (Praktijkondersteuning Zuidoost-Brabant), heeft Nippur een eerste versie van een datawarehouse mogen ontwerpen en implementeren. Met de data in dit datawarehouse is (onder andere) een omvangrijke KPI-rapportage gebouwd. PoZoB heeft geen eigen ICT/BI-afdeling, maar er zijn toch meerdere keren per jaar aanpassingen in de KPI-rapportages nodig of wenselijk. Dit resulteerde in de uitdaging om een zo flexibel mogelijke oplossing te bedenken en implementeren.

KPI-Framework
Als oplossing voor deze uitdaging is in en op de datamart-laag van het datawarehouse een KPI-framework gebouwd. Dit framework stelt de data-analisten van PoZoB in staat om zelf de logica voor KPI-berekeningen te onderhouden, nieuwe KPI’s toe te voegen of bestaande KPI’s af te voeren, zonder ICT/BI-ondersteuning en buiten de datawarehouse database. De enige manier om dat te kunnen bereiken is door zoveel mogelijk metadata-gestuurd te werken.

Bovenstaand schema toont de componenten waarmee het KPI-framework is gerealiseerd:
• De benodigde metadata voor een verzameling KPI’s wordt bijgehouden in een MS excel werkboek en kan met een druk op de knop verwerkt worden in de metadata-database.
• Een in de database opgeslagen procedure genereert op basis van de KPI-metadata verschillende KPI-views. Een KPI-view sommeert de gegevens in KPI- basisdata tot een bepaald aggregatieniveau en berekent additionele ratio’s na aggregatie. De KPI-views worden gebruikt in rapportages/dashboards.
• KPI-basisdata bevat de meest elementaire gegevens die voor de berekening van KPI’s benodigd zijn en wordt gevuld door een verzameling KPI-scripts (SQL-scripts).
• SQLCMD (de SQL-server opdrachtregel interface) wordt voor de berekening van een KPI uitgevoerd met als parameters het betreffende KPI-script, een peildatum en een zorgprogramma.
• Alle uit te voeren berekeningen voor een bepaalde KPI-rapportage zijn verzameld in een batch bestand.

De KPI-scripts zijn gedurende de bouwfase meerdere keren herzien waardoor de uiteindelijke opzet van de scripts maximaal gestandaardiseerd is. Dat wil zeggen dat de opzet identiek is voor alle scripts. De data-analisten, die tijdens dit project voor het eerst met SQL in aanraking kwamen, hebben in een relatief korte periode voldoende SQL-kennis opgebouwd om de scripts aan te kunnen passen wanneer dat gewenst is.

Conclusie
Al vele jaren maken Nippur consultants gebruik van datawarehouse generatie-software (vaak Quipu). Die software ondersteunt bij reverse-engineering van bron-databases en het genereren van de datamodellen die onderdeel uitmaken van de datalogistieke keten van een datawarehouse. Naast de datamodellen wordt ook code gegenereerd om de datamodellen fysiek te implementeren en om data door de datalogistieke keten te kunnen transporteren. Hiervoor gebruikt Quipu een uitgebreide metadata repository.

Wanneer we vervolgens additionele oplossingen of specifieke dataverzamelingen in datamarts opbouwen zijn we vaak geneigd om dit ‘hardcoded’ in SSIS, Powercenter of SQL Stored Procedures te bouwen. Gegevens worden rechtstreeks, vanuit de ter beschikking staande datawarehouse structuren, getransformeerd naar een gewenste targetstructuur in de datamart inclusief filtering en/of aggregatie. Voor iedere nieuwe targetstructuur wordt daarmee als het ware een maatwerkoplossing voor een specifiek doel gerealiseerd.

Door ook bij het realiseren van datamarts of rapportageoplossingen meer gebruik te maken van metadata, wordt de oplossing eenvoudiger onderhoudbaar. Zodoende kan de business minder afhankelijk gemaakt worden van de beschikbaarheid van schaarse ICT- en/of BI-resources voor het onderhoud van die structuren.

Ook kan een meer metadata-gestuurde oplossing ervoor zorgen dat database objecten niet door een ontwikkelstraat (OTAP) hoeven waardoor de business veel sneller in staat is (binnen een uur of enkele uren) om aanpassingen in een KPI-rapportage door te voeren. Ik heb tijdens mijn consultancy-opdrachten releasekalenders meegemaakt met doorlooptijden van enkele dagen tot en met twee maanden.
Tenslotte heb ik het als een extra uitdaging ervaren (leuker werk) om de oplossing meer metadata-gestuurd te maken. Het nadenken over hoe een deel van de oplossing metadata gestuurd gemaakt kan worden levert een verbeterd inzicht in de kern van de problematiek die je probeert te adresseren.

Marc Sanders is BI Consultant/DWH Architect bij Nippur.