“Signalen die wijzen op de noodzaak van een volgende stap voor jouw BI-omgeving”.
Deze blog is onderdeel van de themareeks ‘Management & BI’. De themareeks is bedoeld voor managers die wat meer willen weten over Business Intelligence, maar dan alleen de essentie in begrijpelijke taal en zonder alle technische termen en hypes.
Je hebt jouw front-end BI-tool clients uitgebreid met een front-end BI-server component. De power-users hebben nu een centrale component waar ze hun rapportages en dashboards kunnen maken en onderhouden. Met voldoende discipline treedt hergebruik op en wordt jouw managementinformatie consistenter. Opnieuw tijd gewonnen, maar zonder verdere BI-componenten kent ook deze oplossing een einde. Wat zijn de signalen waaruit blijkt dat deze oplossing te kort gaat schieten? En wat dan?
Schets van de huidige BI-oplossing
Je gebruikt een complete, state-of-the-art front-end BI-tool. Dit is een combinatie van een centrale BI-server, een beperkt aantal BI-tool clients met een ontwikkellicentie voor de power-users en een groter aantal BI-tool clients met viewer-licentie voor de managers. De BI-tool wordt gevoed met bedrijfsdata uit de ‘off the shelf’-bedrijfssystemen voor je boekhouding, CRM, voorraadbeheer en facturatie.
Op de server-component van de front-end BI-tool kunnen centraal rapporten en dashboards worden opgeslagen. De power-users maken en onderhouden deze centrale dashboards dankzij hun BI-tool developer clients. De dashboards worden vanuit de server gepubliceerd naar de BI-clients met een viewer-licentie. Het centraal benaderbaar maken van de dashboards werkt potentieel bevorderend op de consistentie van de managementinformatie. Tenminste, als de power-users voldoende discipline vertonen om dashboards en hun ingebouwde logica te hergebruiken. Want het gebruik van de BI-server bij de ontwikkeling en het onderhoud van dashboards is facultatief. De power-users krijgen door de BI-server en de developer license een formelere rol als BI-ontwikkelaar.
Waar gaat het mis?
De belangrijkste indicatoren dat er iets mis gaat bij deze aanpak zijn:
- Het maken van nieuwe managementinformatie ging eerst lekker vlot, maar neemt toch weer steeds meer tijd in beslag;
- Het lukt niet goed om data uit meerdere bronnen te combineren tot managementinformatie.
- Naarmate het aantal dashboards groter wordt, stijgt de verwarring over wat de laatste versie van een dashboard precies is.
- Naarmate de hoeveelheid brondata toeneemt, wordt de responsetijd van de BI-tools steeds langer.
- Het gemis van een goed geregelde historie van brondata wordt groter.
Waar komt dit door?
Alhoewel ik managers niet wil lastigvallen met technische termen, wordt het tijd om een uitleg te geven over een belangrijk constructie-aspect van BI-omgevingen. Ik hou het wat algemeen, maar een zeker begrip voor de manier waarop BI-omgevingen ingericht worden, is van groot belang om de de gebruikslimieten van front-end BI-tooling te kunnen plaatsen. Als je trouwens wat meer wilt weten over BI-omgevingen zonder de technische poespas, dan kun je altijd ons eBook The 10 Need to Know’s rond BI voor managers downloaden.
De primaire functies die een BI-omgeving kent zijn:
- brondata ophalen
- brondata opschonen
- brondata transformeren
- brondata combineren
- brondata opslaan en historie opbouwen
- brondata omzetten naar een multidimensionale datastructuur
- managementrapportage genereren
- managementinformatie distribueren.
Als je gebruik maakt van een front-end BI-tool als enige component in je BI-omgeving dan moet deze tool alle functies uitvoeren. Het is belangrijk om te begrijpen dat er maar één plek is in de tool om dit te doen, namelijk: het rapport of het dashboard dat de ontwikkelaar wil bouwen.
Dat betekent dat de logica voor de brondata-bewerking die nodig is voor een dashboard, ook in dat individuele dashboard is geprogrammeerd. Toch is de logica van de brondata-bewerking in veel gevallen gelijk voor brondata die in meerdere dashboards gebruikt wordt. Dit vormt twee grote problemen:
- Het is niet efficiënt om logica te dupliceren over alle dashboards, maar nog belangrijker; dezelfde logica gedupliceerd in diverse dashboards gaat onderling verschillen, zeker tussen individuele ontwikkelaars. De dashboards worden door deze constant terugkerende logica onnodig complex en een wijziging in de brondata betekent dus ook dat meerdere dashboards moeten worden aangepast.
- De complexe logica voor het bewerken van brondata komt constant in elk dashboard terug en wordt daar iedere keer opnieuw uitgevoerd, voor elk dashboard apart. En dat terwijl Front-end BI-tools wel goed zijn in het genereren van dashboards, maar veel minder in het efficiënt uitvoeren van de brondata-bewerking.
Een klein aantal dashboards is te managen
In bezit zijn van een BI-server component is een voordeel. Daarmee kun je in ieder geval - uitgaande van afdoende discipline - de logica zoveel mogelijk centraal ter beschikking stellen voor toepassing in de dashboards. Zo beperk je de onvermijdelijke inconsistenties.
Als je niet meer dan zo’n tien tot twintig dashboards hebt en de hoeveelheid en diversiteit van de brondata gelijk blijft, hoeft dit alles geen direct probleem te vormen. Het komt echter vaker voor dat het aantal dashboards stijgt, met uiteenlopende versies en toenemende verwarring over het juiste cijfer op het juiste rapport. Ook zal blijken dat de responsetijden van het genereren van het dashboard, alsmede de maaktijd van nieuwe dashboards of aanpassingen daarop, steeds langer gaat duren. In een groter bedrijf of in een groeiend bedrijf komt er onvermijdelijk een punt dat je een volgende stap moet gaan maken. Sommige BI-tools hebben een extra databewerkingscomponent, denk bijvoorbeeld aan QlikView. Deze optie verlengt de levensduur van front-end BI-tools, maar let wel; een dergelijk component is geen structurele oplossing. Na verloop van tijd ontstaat toch de behoefte aan een specifiek toegesneden datalogistieke tool.
Next Steps
Het feit dat de meeste complexiteit van het genereren van MI in de desktop-BI oplossingen in de rapportage-tool ligt, wordt bij de groei van het aantal rapporten en bronnen de ontwikkeling steeds meer belemmerend. Het scheiden van de logica voor brondata-bewerking en de logica voor het genereren van de dashboards is de volgende stap. Om dit structureel aan te pakken, moet gemeenschappelijke functionaliteit uit de BI-tool naar een centrale oplossing met daarvoor beter geschikte (ETL/DBMS-) tooling worden verplaatst.
Het eerste data warehouse
Om daar te komen moeten een aantal drempels worden genomen. Deze komen voort uit een combinatie van uitdagingen en obstakels bij het bouwen van het eerste data warehouse: slechte planning (project/ontwikkel-attitude), zwakke datakwaliteit, de ondernemingscultuur en de intensiteit waarmee de individuele BI-tools worden gebruikt en de daarmee samenhangende weerstand van eindgebruikers om hun “vrijheid” op te geven. De kosten en de kennis en moeite die in een data warehouse en de bijbehorende datamodellering en DI/DBMS-tooling gaat zitten, zijn ook vaak inhibitors. Daarom ontstaat een eerste data warehouse ook meestal binnen de afdeling die het meeste baat heeft bij snelle en correcte cijfers en die daar dus ook in wil investeren. Die afdeling (bijv. Marketing of Finance) is vaak eigenaar van het eerste data warehouse.
Dit is feitelijk de eerste echt structurele stap in de BI-omgeving. Een groot deel van de complexiteit uit de dashboards aangaande brondata-bewerking verhuist naar de centrale datalogistieke component, die daar uitermate geschikt voor is. Hiermee wordt brondata maar één keer opgehaald, geschoond, bewerkt, getransformeerd en daarna opgeslagen in een data warehouse. De complexiteit van de logica in de dashboards reduceert sterk en daarmee ook de performance (responsetijden en maaktijden) van de dashboards. Bedenk wel, als je lang met deze stap wacht dan heb je veel dashboards en dus veel migratiewerk te doen. Alle rapporten moeten immers worden herschreven om de data bewerkingslogica eruit te halen.
De afdeling die het eerste data warehouse in de organisatie introduceert, neemt één van de belangrijkste stappen bij het volwassen worden in het gebruik van Business Intelligence. Je kunt hiermee jaren vooruit, meestal zo rond de vijf tot tien jaar. Daarna zijn weer extra maatregelen nodig, waarover ik in de volgende blog in deze reeks vertel.
Als je een keer wilt kijken welk soort BI-omgeving het beste bij jouw situatie en requirements past, gebruik dan onze gratis BI-IntroScan. Deze is direct online te gebruiken en genereert meteen een indicatie over welke BI-omgeving het best bij jou past. Vergeet niet om de user guide voor de BI-IntroScan te downloaden. Daarin vind je wat onze BI-IntroScan voor je kan betekenen, welke resultaten je kunt verwachten en een toelichting op het gebruik van de resultaten.
