“Op termijn moet QlikView onderdeel worden van een bredere oplossing”.
Deze blog is onderdeel van de themareeks ‘BI-tooltips’. Deze themareeks is bedoeld om interessante nieuwsfeiten en gebruikstips voor specifieke BI-Tools te publiceren. Deze tooltip behandelt het gebruik van QlikView in high-performance omgevingen.
QlikView is één van de BI-tools die ook een data-logistiek component bevat. Hierdoor kunnen meerdere databronnen en grotere volumes worden gebruikt. Toch kent een dergelijk combi-scenario ook een eind en komt een functioneel breder, separate ETL-tool in beeld.
Inleiding
Er zijn verschillende manieren om van gegevens uit één of meerdere bronnen tot een dashboard te komen. Je kunt aparte tools gebruiken voor enerzijds de ontsluiting van de gegevens (back-end functies) en anderzijds het presenteren van informatie (front-end functies). De BI-tool QlikView heeft naast front-end functies ook back-end functies zodat je in principe het hele proces van zowel data-ontsluiting, als informatiepresentatie met QlikView kunt uitvoeren. Mede hierdoor is QlikView breder inzetbaar en flexibeler dan BI-tools met alleen font-end functies.
Met behulp van de back-end ETL-component van QlikView is het ontsluiten en combineren van meerdere bronnen (databases) goed te realiseren. Uitgaande van een goed gestructureerde omgeving (zie ook de blog “BI-Tooltip: Hoe beheer je een self-service BI-tool, zoals QlikView?”) kun je hiermee ook meer complexe BI-vraagstukken beantwoorden.
Maar wat nu als er meerdere tools van die gestructureerde data gebruik moeten maken? Of als er wensen zijn om eindgebruikers gegevens te kunnen laten wijzigen die vervolgens teruggeschreven moeten worden naar de bronsystemen? In hoeverre is QlikView dan toereikend en wat kun je doen om aan alle eisen en wensen te voldoen?
Laten we eens kijken naar een praktijkvoorbeeld.
Een forecasting applicatie
Als praktijkvoorbeeld nemen we een organisatie op het gebied van chain supply. In het distributiecentrum komen vele items aan die vervolgens naar locaties in heel Europa worden verscheept. Veel van deze items kennen een seizoensgebonden vraag en de meeste items hebben een afgebakende levensduur.
De te verwachten vraag (forecast) naar een item wordt aan de hand van de historische vraag berekend in QlikView. Hiermee kunnen inkopers bepalen hoeveel items ze moeten bestellen. Te veel voorraad met het risico dat items niet meer besteld worden leidt tot extra kosten. Te weinig voorraad leidt tot het niet voldoen aan verplichtingen en klantontevredenheid.
De benodigde (historische) gegevens over de voorraad en de orders komen uit verschillende systemen en worden ontsloten met QlikView.
Zoals in de grafiek te zien is, wordt historische informatie over de berekende vraag en de gerealiseerde vraag gebruikt om inzicht te krijgen in de te voorspellen toekomstige vraag. Maar dit is niet voldoende. De toekomstige vraag hangt af van meerdere factoren die niet allemaal af te leiden zijn uit de historische vraag. Inkopers willen dan ook maximaal invloed hebben op de berekening van de forecast door zelf allerlei parameters in te voeren.
Voor deze forecasting applicatie koos de betrokken organisatie voor een totaaloplossing in QlikView (met een extensie), waarbij de door de inkopers gewijzigde parameters werden opgeslagen in een database en dagelijks verwerkt in de bronsystemen. QlikView fungeert hier dus ook als ETL mechanisme, schrijft wijzigingen in een database en is een doorgeefluik terug naar de bronnen.
De inkopers vonden echter dat het tunen van parameters door deze dagelijkse herberekeningsmethode te lang duurde en verlangden een snellere oplossing.
Een snellere oplossing betekent een snellere verwerking van gewijzigde parameters in de brongegevens. Daarmee wordt het systeem bijzonder performance-gevoelig en komen we in een situatie waar we het gebruik van front-end BI-tools (met een ETL-component) als totaaloplossing moeten herzien.
High-performance systems
Als middel om bijvoorbeeld tijdens agile ontwikkelen aan te tonen dat een dergelijk systeem qua logica werkt is QlikView een prima instrument om te prototypen met een beperkte set gegevens (bijv. 100.000 orders). Maar als de hoeveelheden productiegegevens groeien (in ons voorbeeld zijn er miljoenen orders en stock items), het aantal gegevensstromen meer afhankelijk van elkaar worden, de complexiteit van logica hoog is en eventuele feedback-loops nodig zijn, komen we bij de gebruiksgrenzen van BI-tools als totaaloplossing en is het tijd om even pas op de plaats te maken. Het moment is daar om na te gaan of het ingezette instrument nog wel voldoet als ETL mechanisme en of dit voldoende toekomstbestendig is. Ook de mogelijkheid tot wijzigen van gegevens vraagt dan om een robuustere, gebruiksvriendelijkere oplossing.
Ondanks het feit dat het mogelijk is om op beperkte schaal gegevens te wijzigen met behulp van QlikView (in combinatie met een extensie), is deze BI-tool niet het meest geschikt bij performance gevoelige oplossingen met hoge volumes aan gegevens. In zo’n geval geeft een robuust, op maat gemaakte data-invoerapplicatie meer mogelijkheden, stabiliteit en gebruiksvriendelijkheid.
In elke organisatie zal het omslagpunt naar performance-gevoeligheid anders zijn; factoren als het aantal bronnen, hun volumes en complexiteit, de bedrijfskritische aard van de applicatie, de responsetijden voor eindgebruikers en de beschikbare middelen spelen allemaal een rol in de beslissing om op de ingeslagen weg door te gaan of te kiezen voor een meer structurele oplossing. Het wordt dan tijd om een splitsing te maken in de tooling voor de back-end functies en de front-end functies. Volwassen data-logistieke tools kunnen veel grotere hoeveelheden data verwerken en sneller complexere data-bewerkingsfuncties uitvoeren. Ook bevatten zij mogelijkheden om data, zoals parameters, in te voeren. De complexiteit van de forecasting-logica op basis van de verstrekte parameters verplaatst zich dan compleet naar de back-end component. Terwijl de front-end BI-tools zich beperken tot het presenteren van de berekende voorspellingen.
Functionele architectuur
Zodra je je realiseert dat de omgeving een high-performance karakter heeft, is het verstandig om bij de start van het project een functionele architectuur op te stellen. Deze wordt gestuurd door het forecasting business proces dat de inkopers uitvoeren. Vanuit die architectuur kan bewust worden gekozen voor geschikte tools. Zeker bij performance gevoelige systemen is het van groot belang om al in de eerste stadia performancetesten uit te voeren. Start direct met het samenstellen van performance testsets en het beschikbaar krijgen van een representatief testplatform, zodat je het runnen van een performance test snel en zo automatisch mogelijk kunt uitvoeren bij elke oplevering. Dit geeft je veel eerder inzicht of de gekozen oplossing robuust en snel genoeg is en blijft voor de business.
Geen enkele individuele BI-tool is een totaaloplossing voor alle BI-omgevingen, ook al biedt de tool je nog zoveel mogelijkheden. Typische front-end BI-tools, zoals Tableau, QlikView en MicroStrategy, moeten bij high-performance omgevingen vaak beperkt blijven tot hun toepassing in het presenteren van informatie met eventueel lichte berekeningen. Zelfs als deze tools een extra back-end component bevatten, blijkt dat deze functies onvoldoende presteren bij high-performance oplossingen.
Samenvattend
In een high-performance omgeving kun je zeker gebruik maken van de mogelijkheden van een complete BI-tool als QlikView om snel aan te kunnen tonen dat de gevraagde logica werkt op (beperkte) datasets. Voor de productieomgeving is het verstandig om vooral de kracht te benutten van separate tools voor de diverse onderdelen van jouw oplossing om tot een optimaal resultaat te komen.
Als je een BI-omgeving gaat inplannen, kun je ook gebruik maken van onze BI-Introscan die op basis van een tweetal vragenlijsten grofweg voor je berekent welke BI-Architectuur daarbij past. Go check it out. Wil je weten wanneer de volgende blog verschijnt binnen het thema BI-Tooltips? Abonneer je hier dan op deze themareeks.
