Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Waar is de business case toch gebleven?

 

Voor significante investering die een bedrijf doet wordt een business case opgesteld. Deze business case vertelt de investeerder of zijn geld gaat renderen, hoeveel en op welke termijn. Zonder business case geen project, is zo’n beetje de regel. Deze regel gaat inmiddels ook op voor het aanschaffen en inrichten van erp-software. Deze regel lijkt echter niet op te gaan voor bi-projecten. Ik vraag mij af hoe dat komt.

Het opzetten van een goed business case lijkt lastig voor een bi-project. Er wordt geprobeerd om de investering te rechtvaardigen door de verwachte voordelen te vertalen naar SMART-project-kpi's. Maar zo makkelijk is dat niet. SMART houdt onder andere in dat de kpi's kwantificeerbaar, dus meetbaar zijn. Hoe meet je nou de voordelen van een goed ingericht, goed werkend bi-systeem?

In veel van de gevallen zijn de redenen om een bi-project te starten kwalitatief van aard, bijvoorbeeld:

- Compliance aan allerlei regels.
- Beter inzicht in kosten en opbrengsten.
- Terugbrengen van het aantal fte's.
- Betere beslissingen.
- Snellere beslissingen.

Bij elk van de voorgaande redenen kun je je afvragen wat het oplevert in euro's. Vaak wordt de business case uitgewerkt tot het opsommen van de verwachte kwalitatieve voordelen.

In sommige gevallen wordt wel een een aantal goed kwantificeerbare kpi's opgeleverd en uitgewerkt, maar wordt je er als project niet aan gehouden. Wordt er bijvoorbeeld na zes maanden, na een jaar bekeken of de doelstellingen ook behaald zijn?

Wat is dat toch met bi-projecten? Waarom gelden de algemene regels voor investeringsprojecten niet voor bi-projecten? Of is dit niet zo en zijn er voorbeelden te noemen van goed uitgewerkte business cases met kwantificeerbare kpi's?

Zijn bi-projecten dan toch zo anders dan alle andere investeringsprojecten. Ik ben benieuwd naar jullie ervaringen en meningen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2640307). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Je stipt een goed punt aan.
Bij de meeste BI projecten wordt het in de business case paragraaf angstig stil, en komt men niet verder dan inderdaad een opsomming van 'beter' en 'sneller' en 'betrouwbaarder'.
Niets is zo gevaarlijk als je commitment geven aan een project met een brakke business case, want daarbij loop je 2 risico's:
- bij verschuiving van prioriteiten in de organisatie kan een project met een zwakke business case wel eens de dupe worden. Als leverancier zul je daarin dus ook een klant moeten kwalificeren.
- hoe zwakker de business case, hoe lastiger de acceptatie. Want als je de business case niet kunt vormgeven, krijg je vervolgens het volgende dilemma bij de acceptatiecriteria. Want een 'beter' systeem, werk dat maar uit tot een SMART lijstje acceptatiecriteria.

Je 3e reden is trouwens behoorlijk kwantitatief, organisaties zouden maar al te blij zijn als ze FTE's kunnen besparen op routinematig informatievergaarwerk, zodat ze deze mensen voor echt belangrijke zaken kunnen inzetten.

Van de andere kant zijn BI projecten juist ook trajecten die niet rechtstreeks te kwantificeren zijn. Vaak levert een BI systeem alleen meer inzicht in de bestaande processen en daarmee genereerd een BI systeem vragen over de huidige processen en daarmee verbeter projecten die wel kwantificeerbaar zijn. Dit in tegenstelling tot bijvoorbeeld een ERP systeem, dat vaak wel rechtstreeks SMART doelen kan realiseren.

Ik zou het jammer (en dom) vinden om deze projecten daarmee maar niet uit te voeren omdat deze niet SMART zijn te kwantificeren. Een goed ondernemer /visionair ziet de mogelijkheden die BI hem biedt en zal langs de minder heldere SMARTdoelen heen kijken.

Ik reageer zonder dat ik direct ervaring heb met implementatie van BI projecten. BI is voor mij toch de aansluiting met de bronsystemen bij implementatie van (corporate) performance management trajecten. Kijk, daar weet ik nou weer wat meer van. Ik merk dat het zittende management er vooral in moet geloven om aan de hand van een aantal KPI's inzicht te krijgen in hun eigen organisatie. Overtuigd van de toegevoegde waarde, zullen we maar zeggen.Dikke rapporten, ellenlange analyses daar zit niemand op te wachten. Maar wel een mooie vertaling van het effect dat een organisatie wilt bereiken naar concrete te behalen resultaten. De processen om die resultaten te realiseren, zijn de moeite waard om nader te bestuderen, in te richten en te faciliteren. Als je daar dan vervolgens data analyse op kan loslaten, voeg je waarde toe. En dat is dan ook gelijk mijn punt. Een enkelvoudige business case op een BI project gaat het inderdaad afleggen tegen andere prioriteiten. Maar plaats je de doelstelling van een BI project in een hoger plan lees het verbeteren van de dienstverlening, stijgt m.i. de acceptatie- en daarmee de slagingskans. Ik heb dus de indruk dat (veel) BI leveranciers zich te veel focussen op de subdoelstelling van hun project en daarmee hun eigen graf graven.

De kwaliteit van de business case is naar mijn idee afhankelijker van de beslisser waarvoor het opgesteld wordt. Het type project is daar beperkt op van invloed. Hoe sterker de beslisser de organisatie afrekent op de resultaten van de business case, hoe beter de business case wordt voorbereid.

Mijn vraag aan het panel is dus eerder de volgende. Zien we nu echt dat business cases van niet bi projecten zoveel beter zijn, of kunnen organisaties veel leren op het gebied van business cases opstellen en het managen daarvan.

Volgens mij is er niets mis met een business case op basis van kwalitatieve voordelen. We moeten volgens mij ook af van de drang om alles -desnoods gekunsteld- in besparingen of winst uit te drukken. Soms start je projecten gewoon omdat het de kwaliteit van je bedrijfsvoering vergroot. Soms omdat je risico's beter beheerst. De business case van nieuwe kantoorstoelen (een besparing op het aantal rsi gevallen)? Van schilderijen aan de muur? Of van een kennismanagement systeem? Of van e-mail?

Als er al kwantitatieve business cases worden opgesteld, dan wordt het resultaat maar zelden achteraf gecontroleerd. Besparing in menskracht? Is er dan iemand daadwerkelijk ontslagen? Als die mensen andere werkzaamheden zijn gaan doen, wat heeft dat dan opgeleverd? Ik ken veel gevallen waar die rekensommetjes achteraf nooit meer gemaakt zijn.

Je zou wel van een business case mogen verwachten dat het een goede -kwalitatieve en kwantitatieve- onderbouwing geeft van de keuzes die gemaakt worden in termen van architectuur, platform, scope en dergelijke. Daarin kun je wel degelijk -weliswaar aan de kosten kant- onderscheid maken tussen scenarios, korte vs. lange termijn enzovoort.

Deze discussie loopt al sinds de laatste 20 jaar (en waarschijnlijk al langer, maar dat weet ik niet uit eerste hand). Er is wel degelijk een goede business case te maken, als je BI goed toepast. We moeten twee dingen onderscheiden:
1) BI toepassingen. Deze kunnen goed gekoppeld worden aan tastbare prestatie-indicatoren. Het introduceren van een 'fast close' levert besparingen op in de control-omgeving. Een klantsegmentatie-toepassing levert hogere campagne-respons op en meer conversie. Een leveranciers-scorecard levert inkoopbesparingen op. BI-op-het-web voor klanten levert een hogere loyaliteit op en een hogere share-of-wallet.
2) Het gevaar van losse BI toepassingen is versnippering en uiteindelijk zelfs negatieve ROI. Daarom is een BI infrastructuur nodig (toolstandaardisatie, data warehouse, gemeenschappelijke processen en metadata). Deze heeft geen ROI (net zoals een local area network geen ROI heeft, maar toch nodig is), maar voorkomt een negatieve ROI door het ontbreken ervan. Ook dit is tastbaar te maken, zeker omdat dit vaak de toestand van het verleden is.

Hoop dat dit een beetje helpt...

Frank

Wat mij betreft is de businesscase voor BI heel makkelijk te maken. Vraag bij de staf van het management van een organisatie hoeveel uur zij per week gemiddeld besteden aan het bij elkaar harken van informatie, doe dat maal een gemiddeld uurloon, tel er nog wat zelfklus uurtjes bij ... en voila! daar is het bedrag dat er nu dagelijks/ jaarlijks aan wordt uitgegeven. Dit klinkt misschien wat kort door de bocht, maar dat is het natuurlijk ook. Niet zo zeer om de kosten zo in kaart te brengen, maar wel doordat je dan inzichtelijk hebt hoeveel verschillende mensen de beschikbare ruwe data interpreteren. Alleen al het risico hiervan is in veel gevallen voldoende. Natuurlijk begint dan het echte werk, maar stap 1 is genomen.
Tanja

De business case voor BI moet volgens mij gezocht worden in de business. Dat zal over het algemeen een afgeleide business case zijn en is helemaal afhankelijk van de businesscontext. Bijvoorbeeld het verkorten van de salespijplijn van verzekeringen van 5 werkdagen naar 1 dag. Dit levert geld op, toch? BI levert een essenti?le bijdrage door meer inzicht te geven en sturing te bevorderen op relevante indicatoren die de lengte van de salespijplijn be?nvloeden. Maar het is niet het gereedschap dat uiteindelijk verantwoordelijk is voor verkorting van de salespijplijn, dat blijft voornamelijk mensenwerk. Kortom laat de eindgebruikers bepalen wat er te verdienen valt en lever als BI specialist kennis en ervaring voor het maximaal inzetten van het gereedschap.

Ik herken het verhaal van Machiel, de business case ontbreekt vaak in Business Intelligence projecten. Ik sluit me aan bij de personen die aangeven dat een kwantitatieve business case wel degelijk te maken is. De insteek van Tanja (bespaarde hoeveelheid manuur * bijbehorend tarief) is een hele eenvoudige, maar soms voldoende om de business case rond te krijgen. In dat geval prima dus. De baten die Frank noemt (hogere campagne-respons, inkoopbesparingen, hogere loyaliteit, ...) zijn wat lastiger uit te drukken in geld, maar ook dat rekensommetje is wel degelijk te maken en absoluut nuttig. Een kwantitatieve business case levert op senior management niveau nou eenmaal meer draagvlak op dan een business case die slechts kwalitatief onderbouwd is. Op momenten dat het spannend wordt, is dit belangrijk voor de continu?teit van het Business Intelligence project. Mijn advies is daarom om altijd een business case te maken en deze vooral (ook) uit te drukken in geld.

Ik herken het verhaal van de auteur en de bijbehorende reacties. BI komt er te vaak mee weg om geen business case te maken. Dit heeft naar mijn mening grotendeels te maken met de perceptie van de business. Te veel organisaties zien BI als kostenpost, een stafonderdeel dat rapportjes maakt wanneer iemand daar toevallig behoefte aan heeft. Het wordt tijd dat we inzien dat digitale informatie niet gratis is, maar een productiefactor van belang!
Ik ben er daarom voorstander van om altijd een kwantitatieve business case te maken voor ieder BI-project. Wanneer de business niet wenst te investeren in een BI-oplossing is er kennelijk onvoldoende basis of vertrouwen en kun je beter je energie steken in zaken die wel geld opleveren.

Ik vind de business case een interessant gegeven. Ze worden veelal aan projecten gehangen. Je moet echter goed letten op wat je als project definieert: het op te leveren systeem of de cultuurverandering die het met zich mee zou moeten brengen. De directe baten van het op te leveren systeem zullen niet altijd goed kwantificeerbaar zijn, maar focus je eens op de organisatie verandering. Die is natuurlijk veel belangrijker. Hoe leer je mensen in een organisatie met informatie om gaan? Hoe kun je op basis hiervan je eigen processen controleren en optimaliseren en hoe maak je hiermee een verschil ten opzichte van de concurrent. Dat is het nut van BI. Veel bedrijven zitten nog niet in die modus en in deze bedrijven is de ROI van BI moeilijk SMART te maken.

Trouwens, een BI afdeling zou gewoon een gegeven moeten zijn, net als de financiele afdeling, de it-afdeling en de marketing afdeling. Die stel je toch ook niet ter discussie? Dit staat dus los van ROI's en van business cases.

Of de businesscase alleen kwalitatief of ook kwantitatief is is volgens mij van minder belang. Wanneer kwalitatieve doelen worden gekwantificeerd bestaat vaak de neiging deze flink aan te zetten (voorkomen van een jaar gevangenis van onze CEO is toch wel een miljoen waard?) Echter, de projectdoelstellingen moeten wel duidelijk zijn, en regelmatig moet het projectresultaat ook worden getoetst aan deze doelstellingen. Elk project waarbij dit niet mogelijk is is gedoemd te mislukken (of, om reputaties te sparen: sterft een langzame stille dood)en moet direct, vandaag nog, worden gestopt.
De business case voor dit stoppen is makkelijk te maken: opbrengsten zijn er niet, te besparen kosten zijn enorm, denk naast de projecturen aan licenties, hardware (inclusief stroom, gebruikte oppervlakte, koeling) en toekomstige beheeractiviteiten.
En hierin verschilt BI natuurlijk niet van elk willekeurig ander IT project.

Afhankelijk van de volwassenheid van de organisatie kom je vaker de business case tegen. Als er ??n is geldt ook: zonder business case geen project. Voor BI geldt hetzelfde als voor datakwaliteit-, en veel infrastructurele projecten: de 'return' kant is niet goed in concrete en meetbare termen weer te geven. Toch komen we steeds tot de conclusie dat we het moeten doen. Net als het inrichten van een BICC, invoeren van data management, -governance en master data in de organisatie.

Wat er dan op zijn minst moet gebeuren is in de business case aangeven wat we van de veranderingen verwachten met de business, dat kan uitsluitend risicobeheersing zijn, en, (het belangrijkst) blijf controleren of die verwachtingen uitkomen. Business cases worden vaak, nadat ze eenmaal zijn goedgekeurd, tot een akkoord om een project te starten en verdwijnen uit het zicht. Dat kan niet de bedoeling zijn. Het proces rond de business case zou door moeten lopen tot ver na de implementatie van hetgeen het project heeft opgeleverd, en mag wat mij betreft tijdens het project op een tegeltje aan de muur hangen zodat het goed zichtbaar blijft.

Wat is een business case eigenlijk anders dan een gekwantificeerde droom?

Om een solide business case voor BI op te stellen is lef nodig. Het vereist dat de informatie-gebruiker zich durft uit te spreken over de baten die hij met behulp van de informatie hoopt te halen.

BI is tenslotte een middel en geen doel op zich. Een middel dat dient bij te dragen aan de resultaten van de organisatie. Het doel van BI moet dus niet zijn "snellere of betere beslissingen" maar wat je met die beslissingen beoogt (bijv. meer omzet door cross selling, het oplossen van bottle necks in de processen). Het doel van BI is volgens mij evenmin "beter inzicht in de kosten en opbrengsten". Nee, het doel is dat met men dankzij dat inzicht de bedrijfskosten verlaagt of de opbrengsten verhoogt.

Zonder de juiste informatie kunnen dergelijke ?harde? baten niet worden gerealiseerd. Maar het vergt lef om een deel van die baten daadwerkelijk toe te rekenen aan het gebruik van BI.
Niet makkelijk, wel spannend en heel relevant voor het bestaansrecht van BI.

Het is mijns inziens een zwaktebod om een business case te baseren op het besparen van FTE's in het informatieleveringsproces. De grootste besparing zou je dan immers bereiken als je helemaal geen informatie meer levert. En krijg je daarmee een valide business case voor BI?

Bezuinigen op BI is volgens mij dus niet de beste basis voor een business case. Het gaat om het effect van BI op de bedrijfsresultaten. Een goede BI business case is daarom offensief en pakt een deel van de uiteindelijke baten in de business.

Leuke topic, door een paar dagen vrij nu pas mijn reactie.

De topic ligt me echter na aan het hart, zie mijn stukje van vorig jaar:
http://www.computable.nl/artikel/ict_topics/business_intelligence/2492756/1277145/bi-business-case-of-overtuiging.html

Alhoewel ik het stukje nu iets anders zou schrijven, klopt de boodschap nog steeds:

BI omgevingen worden meestal niet ineens gebouwd, maar komen tot stand als optelsom van diverse kleinere BI-projecten, gericht op specifieke rapportages en analyses. Hiervoor kun je per project (met beproefde methoden) rekenen aan een business case, waarbij de grootste uitdaging de kwantificatie van 'zachte' benefits zoals 'meer inzicht' is.

Tegelijk heeft een bedrijf ??n coherente BI architectuur en infrastructuur nodig, waaraan ieder afzonderlijk project zijn bijdrage levert, anders wordt het een rommeltje. De kosten hiervan zijn deels direct aan individuele projecten (business cases) toe te wijzen, en moeten deels worden uitgesmeerd over de individuele BI-projecten.

Voor het besluit om een individueel project te starten, kun je dus goed een business case opstellen. Maar de initi?le investeringen in een solide architectuur zullen per project moeten worden afgeschreven. Hiervoor kun je dus geen business case opstellen. Alleen een overtuigde en ondernemende organisatie durft deze stap te nemen.

Vriendelijke groet, Robert.

In deze ga ik toch redelijk met de insteek van Roelien en Robbert mee. BI ansich is geen doel. De insteek moet zijn om als organisatie in zijn geheel het belang van goede informatie te onderkennen en die wat mij betreft te benoemen als asset. Net zoals dat gebeurd bij bijvoorbeeld kennis (wat is nu eigenlijk de business case van kennis). Met een goed geintegreerd (business) beeld van informatie kan stukje bij beetje een informationele omgeving worden gebouwd. Dit hoeft niet perse een datawarehouse te zijn. Ik ken kwalitatief sterke oplossingen die helemaal niet gebruik maken van een datawarehouse oplossing. Mijn ervaring leert dat als de informatievoorziening goed is, dat dit nieuwe vraag genereert. Vaak blijkt dan pas de waarde van informatie. Ik ken voorbeelden waar met een investering van nog geen EUR 5000, er een cashflow verbetering van tientallen miljoenen ontstond. Uiteraard kon dat alleen maar omdat de gegevens al voorhanden waren. Met de opbrengsten van alleen al die verbetering zijn de kosten van dat forse datawarehouse zeer ruim te dekken.

Verder blijkt informatie van belang voor vernieuwende organisatiestructuren. Waar voorheen de kosten van informatie te hoog waren om je organisatie over meerdere assen gelijktijdig te sturen, blijkt dat nu wel te kunnen, dankzij betrouwbare geintegreerde informationele omgevingen. Blijkbaar zijn we toch (soms) succesvol met de benadering van Tanja.

Mooi om al de verschillende reacties te lezen over het al dan niet opstellen van een business case. Zoals Tanja Ubert stelt is het inderdaad heel simpel: Tel alle tijd die men nodig heeft voor het verzamelen en verwerken van informatie bij elkaar op en vermenigvuldig dit met een uurtarief. Verder wordt gesteld dat een business case al dan niet kwalitatief / kwantitatef moet worden beoordeeld. Als je uitgaat van een 1 op 1 vervanging van bestaande informatie voorziening / vergaring zal een goede kwantitatieve business case niet eens zo lastig zijn om op te stellen. Het is echter mijn ervaring dat het niet mogelijk is om de business een mooie nieuwe BI - omgeving te geven en zeggen dat ze niet meer mogen doen dan dat ze hiervoor deden. Zelfs bij een migratie naar de laatste versie zal de business meer mogelijkheden krijgen dan ervoor.

Hierdoor blijft een kwalitatieve beoordeling over. Ook dit zal echter lastig worden. Een manager neemt nu hopelijk goede beslissingen op basis van de informatie die hij tot zijn beschikking heeft. Indien deze informatie efficienter tot hem komt hopen we natuurlijk allemaal dat hij dezelfde beslissingen neemt die hij hiervoor ook nam maar dan meer onderbouwd. Het risico op foute beslissingen wordt hierdoor verminderd denken we en dus gaat de kwaliteit van de beslissingen omhoog. Maar als de genomen beslissingen eerder goed waren en ze zijn met een betere onderbouwing ook goed is mijns inziens de beslissing zelf kwalitatief niet gewijzigd. Zwakt dit dan de business case af?

Ik denk dat bij het opstellen van een goede business case het uitgangspunt duidelijk gemaakt moet worden dat een 1 op 1 vergelijk met de huidige omstandigheden niet zomaar gemaakt mag worden. Verder zal in de business case een kwantitatieve en een kwalitatieve component opgenomen moeten worden. En niet te vergeten achteraf zal de business case moeten worden geverifieerd.

Zoals Stefan van Duijn al zei is dit een discussie dei we al meer dan 20 jaar voeren en waar we de komende (meer dan) 20 jaar ook nog mee kunnen vullen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×