Onlangs kreeg ik een vraag over de plaats van Big Data binnen BiSL: wat kan BiSL voor Big Data betekenen en andersom? Een goede vraag! Maar om deze vraag te beantwoorden zullen we het eerst eens moeten worden over de vraag: wat is Big Data? Big Data heeft te maken met gegevens die gedeconcentreerd zijn. Hiermee bedoel ik:

– gebruik van gegevens met meerdere eigenaren, zowel publiek als privé;

– gebruik van gegevens die verspreid beschikbaar zijn over meerdere fysieke locaties;

– gebruik van gegevenssets die verspreid beschikbaar zijn met voor elke set aparte gegevensstructuren en gegevensdefinities;

– gebruik van gegevens die aan de ene kant gestructureerd zijn en aan de andere kant ongestructureerd;

– als gebruik van deze gegevens geldt in ieder geval meer dan alleen het verzamelen en opslaan van deze gegevens, maar ook het gericht analyseren en voorbereiden van deze gegevens ten behoeve van de analyse.

Sommige organisaties zijn al langer op zoek naar mogelijkheden om gegevens te gebruiken a la Big Data . Vrij recente technologische ontwikkelingen voorzien nu in deze wensen. Je ziet hier dus een mooi voorbeeld van een technology push waar op bepaalde plaatsen al veel behoefte voor bestond. En anderzijds is dit voor veel organisaties, burgers en overheden een ontwikkeling waar men zich ineens voor geplaatst ziet.

De wijze waarop wordt omgegaan met informatie en data zal veranderen. Aan de ene kant is dit al een lopende verandering die verder wordt gefaciliteerd door de nieuwe technologie en aan de andere kant wordt deze verandering juist afgeroepen door de nieuwe technologie.

Vanuit het perspectief van business informatiemanagement is deze ontwikkeling in mijn optiek niet veel anders dan andere technologische ontwikkelingen die zijn uitgerold over de wereld: internet, laptops en pc’s, communicatiemogelijkheden, mobiele platforms, Cloud etc. Wat hierbij steeds speelt: er zal een bepaalde mate van regievoering moeten zijn. Hierbij dienen relevante aspecten in beeld te worden gebracht en vervolgens moeten antwoorden en uitgangspunten worden bepaald. Op basis hiervan wordt de feitelijke invulling verder vormgegeven. Kan BiSL hierbij helpen? Je zou geneigd zijn om te denken van niet: in het hele BiSL framework wordt niet ingegaan op Big Data, net zomin als op Business Intelligence (BI). Bovendien schieten de oude denkpatronen bij voorbaat tekort voor nieuwe disruptieve technologieën en zijn de oude modellen niet meer te hanteren. Er zijn allerlei nieuwe aspecten die in de oude modellen niet zijn benoemd.

Bij nadere beschouwing zie ik echter wel degelijk het nut van BiSL: binnen BiSL wordt gewezen op het belang van het nadenken over het omgaan met operationele data en het gebruik van informatie in de bedrijfsvoering. Tevens wordt ingegaan op het belang van het onderkennen van ketenpartners met wie informatie wordt uitgewisseld of gedeeld en op het belang van het inregelen van de relaties tussen ketenpartners.

In het kader van het door-ontwikkelen van het BiSL gedachtengoed wordt gediscussieerd en nagedacht over de hiervoor genoemde vragen en van daaruit zullen ontwikkelingen en voorbeelden vanuit de praktijk naar voren komen. Het voeren van deze discussie leidt op zichzelf al tot toegevoegde waarde. Deze ligt mogelijk niet direct op het terrein van de technologie die nodig is op het gebied van Big Data, maar meer op de regievoering daaromheen.

Mijn conclusie is daarom dat BiSL wel degelijk iets kan betekenen voor het omgaan met Big Data. Het blijft nog steeds wel zinvol om te kijken of het BiSL-model nog verdere aanvulling behoeft en ook is er behoefte om te komen tot best practices op het terrein van Big Data en de rol van business informatiemanagement hierin.

Reacties worden gewaardeerd! frank.van.outvorst@thelifecyclecompany.nl

Geregeld word ik bij organisaties gevraagd om de overdracht van projecten naar beheer (en onderhoud) beter te laten lopen. Die vraag komt dan altijd vanuit de beheerorganisatie en wel meestal vanuit business informatiemanagement/functioneel beheer, want zij ondervinden keer op keer dat er vanuit het project eigenlijk te weinig is geregeld op dit punt. Maar ook voor veel projectmanagers is de overdracht en zeker de acceptatie een lastig punt. Ze weten niet wat ze moeten opleveren aan beheer, waar het aan moet voldoen en ze vinden ook niemand om er een klap op te geven. Het is daarom voor een projectmanager verleidelijk om te zeggen: ik zet een beheerder in het project in om de beheerproducten op te stellen en daarmee is direct de acceptatie geregeld. Dit laatste zou echter een onterechte aanname zijn. Op het moment dat een beheerder is ingezet in het project maakt hij/zij deel uit van de opleverende organisatie en niet meer van de accepterende organisatie. De producten die de beheerder in het project oplevert zullen dus alsnog door het ontvangende beheerteam geaccepteerd moeten worden.
Maar hoe zit het dan met Prince2? Daar moet alles toch beschreven zijn en dan wordt het toch makkelijk? Of ligt het weer aan Pino: Prince2-in-name-only?

Op het eerste oog zou je zeggen: in de business case en in de PID zou je dit moeten regelen. Uiteindelijk gaan mislopende projecten altijd mis op dag één: er is aan de start niet goed nagedacht over wat het project moet opleveren en waar dat aan moet voldoen. Prince2 zegt daar wel iets over, maar het blinkt niet uit. Terecht wellicht, want de eisen zullen afhangen van de materie, de organisatie etc.

Daarna zou de verwachting zijn dat het in de sturing is geregeld. Er is toch een projectboard waarin alle partijen vertegenwoordigd zijn? Ja, Prince2 heeft het namelijk over de BUS:

• De Business, de Executive: de vertegenwoordiger van het bedrijf waaraan de waarde van het project wordt geleverd. Dit is de sponsor, de opdrachtgever.
• De Users of Senior User: degene die de gebruikers vertegenwoordigt.
• De Supplier: de leverancier die het project uitvoert en het product of resultaat realiseert

Maar waar zitten dan vertegenwoordigers van de beheerorganisaties? Weeffoutje van Prince2? Ja en nee. Prince2 zegt: de gebruikers zijn de personen die het resultaat van het project gaan gebruiken, bedienen, onderhouden of faciliteren of te maken hebben met de resultaten. De Senior User vertegenwoordigt dus ook de beheerpartijen. En de Senior User moet er dus voor zorgen dat de beheerpartijen aangeven welke producten zij verwachten, wat de eisen zijn aan die producten en dat toetsing en acceptatie plaatsvindt.

Hieruit kan ik concluderen dat Prince2 dit belang wel onderkent, dat de betreffende projecten waar dit mis gaat dus last hebben van Pino, maar vooral dat de Senior User dus een business informatiemanager dient te zijn, diegene die zowel de gebruikersorganisatie vertegenwoordigt als de beheerpartijen! In een meer gebruikte term: de functioneel beheerder. Jammer dat dit in de naam niet terugkomt: de BUS moet geen BUS zijn maar BBS. Met de B van Business informatiemanager. Weeffoutje!

Overigens heeft The Lifecycle Company, als specialist op het gebeid van ASL en BiSL, al veel beheerders geholpen met het opstellen van acceptatiecriteria en met het accepteren zelf, want dat vinden ze wel lastig. Maar het is dus niet alleen dat: het zit ‘m ook in de organisatie van het project: het komt niet in BUS (en niet in de Business case en de PID).