Business Intelligence is een hot item. De afgelopen maanden werd er in de vakliteratuur veel aandacht aan besteed met als gevolg dat het lijkt alsof BI steeds simpeler wordt. Sjoerd Hobo en Rob Peters van QNH Enterprise Intelligence, vinden dit geen terechte vaststelling. BI was en is nog steeds niet simpel. Dit vertekenende beeld wordt volgens de senior consultants veroorzaakt doordat een aantal essentiële stappen binnen BI buiten beeld vallen. De essentie van BI kan echter niet door techniek worden vervangen.
De afgelopen maanden volgden de Business Intelligence-nieuwtjes (BI) elkaar in hoog temp op. De vakbladen (waaronder de Computable) stonden vol met allerlei BI artikelen en ontwikkelingen. Cognos is onderdeel geworden van het grote IBM, Business Objects en SAP zijn samengegaan, Microsoft is flink aan de weg aan het timmeren op het gebied van BI (zeer recent heeft Microsoft nog DATAllegro gekocht, een leverancier van data warehouse appliances (DWH)), Open Source BI rukt op et cetera. Kortom, BI is nog altijd volop in beweging en geniet nog steeds erg veel aandacht, zeker ook voor wat betreft nieuwe BI-technologie.
Al die aandacht voor nieuwe BI-technologie kent echter wel een keerzijde: BI wordt neergezet alsof het steeds simpeler wordt. We zouden bijna kunnen gaan denken dat we een BI-oplossing kant-en-klaar kunnen kopen. ETL tools en BI-tools worden keer op keer verbeterd. Er zijn zelfs leveranciers die BI verkopen in een vorm waarmee je binnen een korte tijd ‘ready' bent. Anderen verkopen een heel snelle machine met database (een DWH-appliance). Heb je problemen met de performance binnen de BI-omgeving, maar ben je nog niet toe aan een DWH-appliance, dan bieden wellicht de in-memory databases een oplossing! Nog mooier zijn de verhalen over de ETL-fabrieken waar je alleen nog vier parameters hoeft in te stellen. Geef uw bron maar, we stellen een paar parameters in en klaar zijn we!
Alsof het allemaal zo simpel is. Nee, BI is helemaal niet simpel: dat was het niet en dat is het nog steeds niet. BI kent een aantal essentiële stappen/onderdelen die de laatste tijd naar de achtergrond worden verdreven, in ieder geval veel minder aandacht krijgen. De techniek lijkt de essentie van BI onder te sneeuwen, maar de essentie van BI kan helemaal niet door techniek worden vervangen!
In dit artikel gaan we terug naar de basis van BI. We brengen weer eens een paar van de essentiële BI onderdelen onder de aandacht.
Informatie-analyse
Sturen op informatie is een heel belangrijk thema binnen BI. Maar op welke informatie dan? Een van de belangrijkste eerste stappen binnen ieder BI-project is het achterhalen van de informatie behoeften van de business. Een schone taak voor de interne of externe (BI-) informatie-analist. Maar hoe gaan we de business nu ontfutselen wat hun informatie behoeften zijn? In ieder geval niet door over dimensies/meetwaarden of sterren te beginnen. Een informatie analist moet via interviews mee kunnen gaan in de omgeving waarbinnen de managers van een organisatie acteren. Inzicht in de bedrijfsprocessen is noodzakelijk om de genoteerde business requirements op een juiste manier te vertalen in een vorm zodat het BI-projectteam er mee verder kan. De informatie analyse is één van de eerste en één van de belangrijkste fasen.
In deze fase spelen BI-tools nog geen enkele rol van betekenis. Wel hebben in het verleden een klein aantal leveranciers van BI-tools getracht kant en klare rapportsuites aan te bieden voor bepaalde doelgroepen (retail, supply chain). Daarvan is het aantal echte succesverhalen op één hand te tellen. Het kon eigenlijk ook niet waar zijn; tool leveranciers die denken te weten hoe een organisatie stuurt op informatie.
Informatie-analyse is een ambacht. Het is en blijft de kunst managers de juiste vragen te stellen en hun antwoorden te vertalen op een zodanige manier dat er een BI-platform op kan worden gespecificeerd. Het vertalen van antwoorden is zo eenvoudig nog niet. De wens om inzicht te krijgen in de omzet per winkel is snel uitgesproken en genoteerd, maar hoe simpel de wens ook lijkt, ambachtelijk inzicht is noodzakelijk. Immers, wat is winkelomzet eigenlijk? Inclusief of juist exclusief retouren? Misschien zijn beide opties waar en van toepassing binnen verschillende afdelingen. Het is de kunst deze vragen te onderkennen en ze te stellen als informatie-analist.
Templates
Voor het vastleggen van interviewresultaten en desk research activiteiten, is het aan te raden templates te gebruiken om volledigheid en eenduidigheid te garanderen. Het opstellen van een informatie-analysedocument (eigenlijk het groene boekje van de BI omgeving) is geen one-time job: nog vele opvolgende keren zal het document, al dan niet door dezelfde informatie-analist, worden aangepast en/of uitgebreid. Met behulp van een template blijft de informatieanalyse op het juiste niveau.
Een slecht uitgevoerde informatie-analyse leidt zonder twijfel tot een onsuccesvol BI-platform. Het succes van een BI-omgeving wordt niet alleen gemeten aan de hand van wat het allemaal wel levert aan informatie, maar ook zeker wat het niet levert. Een onvolledige of onjuist uitgevoerde informatie-analysetraject is zeker niet te corrigeren met een fantastische ETL/BI-tool of database!
Bron-analyse
Als eenmaal duidelijk is geworden welke informatie nodig is binnen de organisatie, kan de zoektocht starten naar het vinden van de data die noodzakelijk is om met behulp van business rules tot de gewenste informatie te komen.
Gedurende deze fase is het belangrijk bronkennis te vergaren. Dit kan door het bestuderen van aanwezige bronsysteem-documentatie (is niet altijd voorhanden overigens) en via interviews met applicatiebeheerders. Ook voor deze fase geldt dat de benodigde bronkennis niet met een simpele druk op een toolknop kan worden geleverd. Onherroepelijk komt er een moment dat er intensief moet worden gekeken naar wat er nu allemaal aan data aanwezig is binnen het bronsysteem, wat de data betekent en hoe de data in de database van een systeem tot stand komt. Ook voor deze fase geldt dat de mouwen opgestroopt moeten worden.
Er zijn tegenwoordig wel diverse tools voor het profileren van de data: zoals voor het bepalen van datakwaliteit en soms zelfs het tekenen van het bron datamodel. Mocht het benodigde bronsysteem echter toevallig een oud mainframe zijn, dan zijn dit soorten hulpmiddelen pas nuttig in zeg fase 2, als al duidelijk is wat je allemaal uit een bronsysteem nodig hebt en een eerste testlevering in de vorm van flatfiles tot je beschikking hebt. Maar let op, een data profiling tool blijft een hulpmiddel en vervangt de Bron Analyse-fase niet.
Zo kan met een data profiling tool de gezochte kolom omzet gevonden worden, maar is dit nu de kolom die moet worden geëxtraheerd? Of moet omzet in de BI-omgeving worden berekend op juiste andere bronkolommen? Dit dient goed uitgezocht te worden.
Architectuur
Over BI-architecturen is al heel veel geschreven, genoeg handvatten voorhanden dus.
Helaas komt het nog te vaak voor dat er niet voldoende wordt stilgestaan en nagedacht over een solide BI-architectuur. Met alle geavanceerde ETL- en BI-tools op de markt, lijkt deze stap overbodig te worden. Niets is echter minder waar. Zelfs met al het moois dat de markt te bieden heeft, is succes nog steeds niet gegarandeerd. Met het zonder een duidelijke architectuur inzetten van bijvoorbeeld een ETL-component is spaghetti snel gerealiseerd. Het gevolg is een onbeheersbaar en mogelijk fout systeem. Het resultaat staat veelal haaks op het gedachtegoed dat hoort bij BI, zoals het snel kunnen inspelen op nieuwe en veranderde informatie behoeften van de organisatie.
Een eerste versie van een BI-architectuur dient opgesteld te worden aan de hand van de visie die een bedrijf op BI heeft, de kwaliteitseisen die aan de BI-omgeving worden gesteld, en de informatie behoeften die de BI-omgeving moet ondersteunen. Zo kan gewenst actualiteit van informatie in de BI-omgeving leiden tot het opnemen van een ODS in de architectuur. Als de basis is bepaald, kan nagedacht worden over de bijbehorende BI-functionele-, BI-data- en -informatie-, BI-integratie- , BI-technologie- en BI-security-architectuur.
Een architectuur dient flexibel te zijn, zodat de architectuur kan worden aangepast/uitgebreid en toekomstige informatie behoeften kan ondersteunen. Met de technologie architectuur sluit je de hele BI-architectuur studie af. Het eerst aanschaffen van tools en het dan pas nadenken over een architectuur is niet de juiste weg.
Modelleren
Kant-en-klaar BI-oplossingen gaan veelal uit van een standaard datamodel. Het datamodel moet echter de beantwoording van de informatievraag ondersteunen. Een deel kan generiek zijn, maar een groot deel is ook bedrijfspecifiek. In het ontwerp worden vele keuzes gemaakt, zoals:
• waar wordt historie bewaard en hoe gebeurt dat?
• welke detail niveau wordt bewaard?
• welke business rules zijn zo belangrijk dat ze in het datamodel worden vastgelegd.
De basis voor deze modelleerbeslissingen is de informatie analyse. Het vertalen van de informatievraag naar een flexibel, gestructureerd en begrijpbaar datamodel is een ambacht, dat niet door een tool kan worden overgenomen.
Conclusie
BI is en blijft op een aantal essentiële onderdelen een ambacht. Nieuwe technologie is natuurlijk erg mooi en ook nodig, maar nog steeds geldt dat daarmee een succesvolle BI-omgeving niet is geboren. Het gedegen uitvoeren van een informatie-analyse, bron-analyse, architectuur-analyse en modelleren is nog altijd essentieel bij het uitvoeren van een succesvol BI-project.
BI is meer dan technologie, zelfs met de meest geavanceerde tools koop je nog steeds geen succesvol BI-platform.
Sjoerd Hobo en Rob Peters, QNH Enterprise Intelligence
Eens! Eerst denken en dan doen!
Tools kunnen het denken (bron analyse, architectuur bepalen, modelleren) wel ondersteunen. Als je begint is alles nog klein en overzichtelijk en lijkt het makkelijk. Als je BI omgeving groter wordt komen de grenzen van het oorspronkelijk bedachtte aan het licht en moet je opnieuw gaan denken. Gelukkig maar, met een druk op de knop zou BI ook niet meer leuk zijn!
Helemaal mee eens. Want uiteindelijk is een BI-project eigenlijk helemaal geen technisch project!
Business Intelligence blijft inderdaad een ambacht, op alle onderdelen! Alleen moeten we nu niet met zijn allen ons volledig gaan richten op uithoren van de business, het het stuk – analyseren van de data, het ontwerpen van mooie architecturen en modelleren van het datamodel. Hoewel we met zijn allen goed zijn in het uitleggen van de noodzaak voor de voorbereidende werkzaamheden is de business vooral geinteresseerd in het resultaat, bij voorkeur morgen opgeleverd.
Hoewel geen enkel bedrijf identiek is in bedrijfsvoering en dus informatiebehoefte zijn grote gemene delers er wel uit te halen. Hierop zijn de appliances ook gebaseerd. Voor veel bedrijven is dit een uitkomst om in ieder geval iets van informatie snel beschikbaar te hebben. Onze taak als consultants is dan om deze appliances in te bedden in een gedegen architectuur, samen te laten smelten in een solide datamodel en dat alles gebaseerd op de juiste informatiebehoefte. Dit kan dus een 2-traps raket inhouden.
Kortom het is inderdaad een mooi ambacht maar we moeten niet uit het oog verliezen dat we het doen voor de business en dus soms, noodgedwongen, snel moeten opleveren en dan een veer moeten laten op andere punten.
Toen ik dit artikel las dacht ik: “Gelukkig, BI is w�l simpel”… De beschreven stappen gelden tenslotte voor elke technologie implementatie en zijn ondertussen goed beschreven.
Ik denk ook dat je met industrie referentiemodellen en standaard BI-applicaties wel degelijk winst kunt halen.
Waar de uitdaging dan wel zit? BI moet antwoorden geven. Van een goede BI functie in het bedrijf mag je verwachten dat het mee kan denken en zowel reactief als pro-actief met vragen van de business omgaat. Dat het ondanks een toekomstvaste architectuur ook flexibel met vragen om kan gaan, zonder altijd gelijk met change request procedures te zwaaien. Dat het data kan analyseren, ook als het nog niet in een stermodel in het data warehouse staat.
Dat is een BI service georienteerde mindset en daar hebben we nog wel wat werk te doen.
Als ik de artikelen uit de afgelopen periode voor de geest haal, wordt vaak door managers een slecht cijfer aan de gebrachte BI/DWH-oplossing gegeven.
Wat volgens mij wordt de informatie-analyse tegenwoordig wel goed gedaan. Het DWH wordt ook opgebouwd volgens het model dat de informatie-analyse vereist. Alleen wordt het daarna daadwerkelijk analyseren van data uit het DWH niet gedaan. Veel wordt het DWH model gebruikt om operationele rapporten op te bouwen, tenminste voor wat ik in mijn korte bestaan als BI consultant tot op heden heb gezien. Moet BI ook geen ingebed proces worden van de organisatie in plaats van een DWH met wat rapporten?
Het mislukken van de BI trajecten ligt daarom ook niet aan de eenvoud van tools maar ook niet aan het ontbreken van een goed NAZORG traject. Inderdaad wordt het bouwen van een BI oplossing steeds eenvoudiger en blijft de informatie-analyse een belangrijk punt in BI projecten. Echter nog belangrijker is volgens mij het traject na het opleveren van een DWH/BI-omgeving. Namelijk managers te leren hoe zij daadwerkelijke van BI gebruik kunnen gaan maken om hun organisatie te ondersteunen. Dus geen standaard rapporten opleveren die uit de informatie-analyse naar voren zijn gekomen maar gebruik maken van “eenvoudige” technologie die bestaat om daadwerkelijke BI analyses uit te voeren. Dus meer gebruik gaan maken van analyse tools waarmee het mogelijk is verder te kijken dan onze neus lang is. Maar wie wil dit gaan betalen? De trajecten zijn veel al prijzig en is het vaak niet duidelijk te maken wat de opbrengsten zouden zijn.
Het klopt dat voor het komen tot een gedegen functioneel ontwerp nog steeds heel veel vakmansschap om de hoek komt kijken echter met de huidige technologische ontwikkelingen wordt de vertaling naar het technisch ontwerp toch een stuk eenvoudiger. Door de snelle ontwikkeling van de hardware (dwh-appliances)is de noodzaak voor halffabrikaten/aggregaten, slim indexeren en andere slagen nodig voor een goede performance, een stuk minder geworden. We kunnen ons focussen op het logische database design ipv het technische design.
Dit zal vooral een daling in de onderhoudkosten tot gevolg hebben want door de performance tuning zijn er in het verleden heel wat systemen opgeleverd waarbij na een aantal jaar veel geld uitgegeven moest worden aan:
invoeren van conformed dimensions, opzetten van halffabrikaten, ontvlechting tussen verschillende datamarts, upgrade naar Oracle 10G met een andere query optimizer,…etc etc
Kortom als de techniek doorgaat zal absoluut de hoeveelheid tijd besteed aan onderhoud afnemen.
Jaco Geluk
http://www.e-mergo.nl
Helemaal mee eens! De term BI impliceert al dat er nagedacht moet worden over de organisatie. En bij voorkeur al voordat je over BI-applicaties gaat nadenken. Het succes van BI-applicaties is rechtevenredig met de mate waarin binnen de organisatie op basis van cijfers gestuurd wordt. Rapportage is daarbij een middel en geen doel op zich. Wat is de toegevoegde waarde van een rapportage als de inhoud ervan nooit leidt tot ingrijpen in de onderliggende processen?
Als bedrijfprocessen helder en efficient worden opgezet en de ondersteunende applicatie hierbij aansluit, wordt daarmee een goede basis gelegd voor een transparante BI applicatie. Zijn de bedrijfsprocessen onduidelijk, dan leidt dit tot workarounds in de applicaties en wordt de BI applicatie gevoed met inconsistente gegevens. En dan heb je veel intelligentie nodig om er weer een consistent geheel van te maken. Jammer.
Dat BI helemaal niet zo simpel is blijkt wel uit het artikel van 21 november. Volgens mij is BI namelijk nog complexer dan de schrijvers in het artikel melden omdat zij een aantal essentiele aspecten van BI buiten beschouwing laten.
Het effectief laten zijn van een BI is namelijk ook afhankelijk van de acceptatiegraad van de geleverde oplossing en daar komen weer eens de softe skills om de hoek. Je kunt nog zo’n mooi BI systeem bouwen maar als het niet geaccepteerd wordt heb je er uiteindelijk niets aan.
Wie wil er nou eigenlijk en BI systeem? En om welke problemen te tackelen dan? Wat zijn de doelen van die belanghebbenden en met welke strategie willen zij dat bereiken? Wel informatie is dan nodig en hoe wordt het aanbod van informatie dan gebalanceerd? En wat te doen met alle oplopende emoties en misverstanden door verschillen in inzicht van definities. Om hier achter te komen zijn goede communicatieskills en een flinke doses emotionele intelligence dus uitermater essentieel in de omgang met de belanghebbenden. Maar ook als je uitstekend kunt communiceren en een emotionele match kunt vinden met de betrokkenen, hoe stel je dan inhoudelijk de juiste vragen?
Zie hier komt de behoefte, inzicht en ervaring met referentiemodellen en bestpractices voor bedrijfsvoering en systeemkunde om de hoek zetten. Daarbij zijn niet alleen modellen benodigd die een interne focus hebben maar ook modellen voor een externe focus. Uiteraard is bronkennis hierbij handig en noodzakelijk, maar vooral ook kennis van wat niet in de bronnen aanwezig is en wat je zou moeten weten. Daarnaast heeft business intelligence niet alleen te maken met meten en weten maar ook nog eens met hoe ga je dan met die kennis om, met het hoe ga je sturen in een organisatie. Naast dit soort kennis en vaardigheden zijn er ook nog kennis en vaardigheden benodigd in de projectaanpak. Grootschalig een BI traject inzetten zonder eerst een aantal pilots uit te voeren en het laaghangende fruit te pakken en bewijs te leveren van de effectiviteit is bijvoorbeeld een van die valkuilen waar menig BI manager nogal eens invalt.
BI is nog niet zo eenvoudig als de schrijvers doen voorkomen. Je hebt er dus ook nog goede communicatieve skills, een dosis emotionele intelligentie, een uitgebreid referentiekader, veel ervaring en zowel een interne als een externe blik bij nodig. Hierbij dien je je hoofd koel te houden als de emoties oplopen wanneer je systematisch en strategisch bezig bent de verwarringen in een organisatie te ontrafelen.
Een goede BI’er…. dat is een held!
Met vriendelijke groet,
Pieter Nierop