Ik betoog in deze blog dat de huidige structuur van business intelligence (bi) waarbij bi in een centrale afdeling is georganiseerd niet goed aansluit bij de organisatiestructuur van grote organisaties die veelal federatief georganiseerd zijn. De oplossing van dit probleem is om bi te laten aansluiten bij de organisatiestructuur van grote organisatie. Geef iedere business unit een eigen bi-afdeling, is dan het motto.
Laatst kwam er een gebruiker naar me toe en ik zag direct dat hij chagrijnig was. ‘Het is toch ook altijd gedonder met jullie it’ers. Hoop gezeur, hoop problemen en op het eind leveren jullie een rapportje dat ik ook met Excel had kunnen maken.’ Ik deed even of ik hem niet helemaal begreep. ‘Hoe bedoel je eigenlijk?’ Dat leidde tot een lange treurzang. Het kwam erop neer dat hij al twintig jaar op een informatieafdeling werkte, waarbij hij business intelligence-projecten vanuit de gebruikers moest begeleiden. Hij had het idee dat het lastig was en bleef om die projecten binnen een acceptabele tijd en budget tot een goed einde te brengen. Ondanks snelle machines, sterk verbeterde netwerken, veel betere software, bleven business intelligence-projecten berucht vanwege de budgetoverschrijdingen en lange duur. ‘Hoe is het toch mogelijk dat jullie zo blijven klungelen?’, voegde hij er nog pesterig aan toe.
Het argument dat we niks geleerd hadden, raakte me wel. Ik bracht er tegenin dat we op een aantal fronten wel degelijk forse vooruitgang hebben gemaakt. In chique woorden zeggen we dan dat business intelligence een commodity is geworden. In gewoon Nederlands betekent dit dat we nu wel weten hoe we gegevens vanuit bronsystemen naar een centraal data warehouse moeten brengen. En we weten ook wel hoe we die gegevens in mooie rapporten moeten zetten. En de ervaren projectleiders kunnen daar ook wel een heel behoorlijke schatting voor afgeven. Maar die schattingen worden wel onder randvoorwaarden afgegeven.
Voorbeelden
Mijn standaard voorbeeld is dat ik ooit eens een bron had ontsloten bij een grote bank. Van te voren waren redelijk strenge deadlines afgegeven: de gebruikers moesten na drie maanden hun rapporten hebben. Maar er was ook voldaan aan de noodzakelijke randvoorwaarden: de gebruikers wisten precies welke rapporten ze wilden hebben en er was gezorgd voor een goede toegang tot de source systemen. Kortom: er was geen enkel probleem om direct aan het design te beginnen. Ik had dat design op een standaard manier opgezet. Dat werd vervolgens naar India gestuurd naar een ontwikkelaar die goed op hoogte was van standaard technieken. In korte tijd had hij het systeem geprogrammeerd. Vervolgens werd alles in productie genomen en werden de rapporten gemaakt. In drie maanden had de gebruiker toen inderdaad zijn rapporten. Hoezo problemen? Ik weet dat alle collega’s met wat ervaring in huis ooit zo’n situatie hebben meegemaakt. Het kan dus wel.
Maar hoe komt het nou dat de gebruikers het idee hebben dat hun it-afdelingen maar steeds weer het wiel opnieuw moeten uitvinden?
Ik denk dat daar verschillende oorzaken voor zijn. Maar die oorzaken zijn wellicht terug te voeren op het feit dat bedrijven zich ontwikkelen tot afzonderlijke business units die een eigen verlies- en winstrekening hebben en zich weinig gelegen laten liggen aan andere business units, ook al zijn die onderdeel van hetzelfde bedrijf. Een klein voorbeeld om dat te illustreren. Bij een grote organisatie hadden we gegevens uit een financieelsysteem nodig. Wij waren van de centrale business unit. Zij waren van de afdeling Europa. Het heeft bijna twee jaar gekost om de gegevens inderdaad te krijgen. Je maakt mij niet wijs dat het leveren van gegevens bovenaan de prioriteitenlijst van de afdeling Europa stond. Ik denk dat het leveren van data te weinig bijdroeg aan de winst van afdeling Europa om je er echt druk over te maken. Een ander voorbeeld. Wij van de centrale business van het bedrijf hadden toegang nodig tot een systeem van de afdeling Amerika. Afdeling Amerika had drie maanden nodig om een user-id en wachtwoord af te geven. De reden was dat afdeling Amerika bang was dat we de gang van zaken in Amerika zouden verstoren. Blijkbaar zorgden we voor bedreiging voor de winstpositie van afdeling Amerika.
Grote organisaties zijn dan in feite koepels boven business units die ieder hun eigen broek moeten ophouden.
Het probleem
Volgens mij ligt daar ook de crux van het probleem. Business intelligence is in de koepel gepositioneerd en heeft data nodig van de afzonderlijke business units. En het leveren van de data genereert wel kosten bij de afzonderlijke business units, terwijl de winst van de business intelligence terecht komt bij de koepel.
Maar daarmee heb je ook de oplossing van dit probleem. De structuur van business intelligence (bi) moet aansluiten bij de verantwoordelijkheden van de afzonderlijke onderdelen. Je kunt dan de centrale bi opsplitsen naar afzonderlijke onderdelen bi, die in de afzonderlijke business units worden geplaatst. We krijgen dan per business unit een afdeling business intelligence. Daarmee hebben de afzonderlijke business units ook de mogelijkheid om bi op een voor hen optimale manier in te richten. Dat impliceert dat de afzonderlijke business units ook de winst kunnen incasseren van hun business intelligence. Ze hebben dan de kosten en de winst van bi. Volgens mij hebben we dan een goede afweging tussen kosten en opbrengsten van bi. Vragen als: ‘is dit rapport nu echt nodig?’ kunnen dan relatief simpel beantwoord worden, omdat kosten en opbrengsten op een kostenplaats terugvallen.
Werken met kleine bi-omgeving
Op centraal niveau kunnen we werken met een kleine bi-omgeving die alleen de summaries bevat die afkomstig zijn van de afzonderlijke bi-afdelingen van de afzonderlijke business units. We krijgen op die manier een federatie van bi-omgevingen met detailanalyses die plaatsvinden bij de afzonderlijke business units, terwijl de overkoepelende analyse plaatsvindt in de koepel.
Ik zie veel voordelen bij deze manier van werken. Een groot voordeel is dat de analyse van detailgegevens kan gebeuren bij de afzonderlijke business units. Daar hebben we ook de kennis zitten van die detailgegevens. De data-analist heeft dan relatief eenvoudige toegang tot die kennis omdat ze beiden bij de business unit werken. Dat lijkt me een groot voordeel voor die data-analist omdat hij tot op heden verbonden was bij de centrale koepel en het voor hem lastig was om toegang te krijgen tot kennis bij afzonderlijke business units. Vanuit die centrale koepel zijn afzonderlijke business units veelal een terra incognita, waar je niet weet wie op de hoogte is van welk business proces.
Dan de hamvraag: ‘maar kan het ook?’. Er waren vroeger toch allerlei redenen om business intelligence centraal neer te zetten. Veel van die redenen hadden van doen met technische beperkingen die inmiddels achterhaald zijn. Vroeger draaiden de systemen op veel kleinere machines die additionele bi niet konden verwerken. Er was ook veel minder opslagruimte. Er was gewoon geen plaats voor bi. Ondertussen is er wel plaats gekomen; de servers bij de buisness units zijn een stuk krachtiger geworden. De kennis van bi is bovendien een stuk beter geworden. Kortom: het is mogelijk om de business intelligence bij business units te positioneren. Het kan. Laten we dan maar doen.
Als je iedere BU zijn eigen afdeling BI geeft, krijg je weer getouwtrek tussen de Centrale BI en de BU BI, met dezelfde problemen als hierboven beschreven. Communicatie is het toverwoord.
Hoi Tom,
Waar je BI gaat organiseren is afhankelijk van de (KPI)structuur en cultuur in een organisatie. Daarnaast is het ook van belang om te kijken naar de informatie behoefte per bedrijfsonderdeel maar zeker ook naar de behoefte op corporate niveau. Deze ingrediënten bepalen boe BI te organiseren. Als je daarnaast ook kijkt naar de waarde van data voor een totale onderneming, kom je waarschijnlijk tot het inzicht dat er meer behoefte gaat ontstaan voor data op corporate niveau. Als gevolg daarvan zal de datakwaliteit en data governance door de gehele organisatie van betere kwaliteit moeten zijn. En dat organiseer je over de gehele organisatie heen. Dit heeft weer tot gevolg dat BI(EIM) op corporate niveau een belangrijkere rol zal gaan spelen.
Tom,
Bij decentrale organisaties moet je de bi ook decentraal aanvliegen, helemaal met je eens. Maar er zijn ook centrale organisaties. Het is een kwestie van custom fit voor de klant. Zo vind ik het te gemakkelijk gesteld. Bovendien kan je ook decentraal gedreven centraal neerzetten, bijvoorbeeld 1 appliance, met wel de mogelijkheid voor de decentrale business units om hun informatie daar te laten hosten. De voorbeelden die je aanhaalt hebben te maken met het principe dat informatie laten aanleveren pas werkt als de aanleverende partij er ook zelf gebruik van maakt. Anders krijg je nooit de juiste prioriteit, laat staan kwaliteit.
Het doel van Business Intelligence is meer informatie (intelligence) te halen uit de reeds aanwezige data. Juist door data van verschillende afdelingen bij elkaar te brengen ontstaat meer en betere informatie/inzicht. Iedere afdeling heeft er dus belang bij data beschikbaar te stellen aan de rest van de organisatie omdat zij daardoor ook over meer data kan beschikken en dus betere beslissingen kan nemen. Data is dus inderdaad een corporate belang.
Echter, iedere afdeling zal juist specifieke elementen uit de aan hen beschikbaar gestelde data willen gebruiken. Op hun eigen manier die het best aansluit op hun werkwijze. En daarvoor heb je data specialisten (noem ze BI-ers) nodig die kennis hebben van het corporate datamodel, die weten welke betekenis data heeft en die dus de juiste rapportages kunnen bouwen die écht worden gebruikt.
Ik ben dus van mening: regel het verzamelen van de data in op corporate niveau, stel data zonder beperkingen beschikbaar aan afdelingen en laat hen hun eigen rapportages maken met ondersteuning vanuit een klein centraal BICC.
Als de business afhankelijk wordt van adviezen van deze managing consultant dan kunnen ze inderdaad beter een aquarium kopen met een inktvis erin, teveel dode vis projecten zijn tenslotte gewoon het gevolg van de verkeerde KPI’s. Recentelijk kwam uit onderzoek naar voren dat cijfers in BI systemen vaak even betrouwbaar zijn als rijks ICT-dashboard omdat een cross-check nagelaten wordt. Of zoals ik een reactie op SAP-er-de-flap stelde zijn cijfers hierin nogal manipuleerbaar door ‘exemption’ management, het weglaten van de onwelgevallige uitkomsten om zo de resultaten op te poetsen.
BI gaat volgens mij in essentie namelijk om de operationele performance van de organisatie te verbeteren. Simpelweg dus om het rendement van activiteiten en hierbij hoeft het dus niet enkel en alleen om kosten en baten te gaan want sommige dingen zijn onbetaalbaar, zoals vertrouwen bijvoorbeeld.
Als er 3 maanden op een userid gewacht moet worden of 2 jaar op een data-export dan is er heel iets anders mis en dan zou ik dat maar eerst eens gaan oplossen. Dit is weer een voorbeeld van een complexe oplossing zoeken voor een simpel probleem.
Scope en businesscase zijn niet alleen factoren voor BI. Beetje afdeling heeft wel zijn eigen agenda. Projecten per definitie. En afdelingen en projecten krijgen bestaansrecht, omdat er kennelijk noodzaak toe was. Lekker flex decentraal wendbaar zijn enzo.
Of iemand dacht “het kan, dus laten we het dab maar doen” 🙂
De vraag is wat de functie is van de centrale BI-afdeling. Als het is om op basis van wat door decentraal geleverd wordt aan centraal, HQ van informatie te voorzien, dan kan het prima werken. Dan is het slechts consolideren van KPI’s en presenteren.
Als de functie is om centraal de (centrale) bronnen te ontsluiten en voor de decentrale organisatie onderdelen kpi’s en rapporten op te stellen, dan is de kans op een succesvol traject minimaal. Ieder decentraal onderdeel zal op haar eigen manier met de data om willen gaan, en het is heel lastig om een “one size fits all” oplossing te bouwen.
In dat geval is het het beste om de functie van centraal BI te beperken tot het beschikbaar stellen van geharmoniseerde data en gemeenschappelijke kpi’s, en decentraal toegang te geven om haar eigen rapportages en analyse-oplossingen hier tegen aan te zetten.
Wellicht de gedachte van afdelingen loslaten en gaan organiseren rondom End-2-End processen … informatie is inmiddels een belangrijke factor in elk proces, dus daarmee is ook een ‘BI’-verantwoordelijke en/of team daarbij betrokken.
Vervolgens afstemming organiseren via de ‘centrale koepel’ als ondersteuning en voor besluitvorming mbt prioriteitstelling bijvoorbeeld. Centrale functie zul je moeten blijven houden om wildgroei in opzet en architectuur te voorkomen. Verder inderdaad eens om BI in de business te beleggen, het is immers Business Intelligence.