In de wereld van IT zien we dat er sprake van steeds verder gaande specialisatie en componentisering.

Leveranciers specialiseren zich op 3 verschillende assen: product/dienst, technologie of markt. Specialisatie op product/dienst betreft bijvoorbeeld: hardware, software, ontwikkeling, onderhoud, installatie, migratie, inregeling, consultancy, PaaS, SaaS. Specialisatie op technologie: Microsoft, SAP, Linux, Google etc., specialisatie op markt: bijvoorbeeld overheid, MKB, zorg, energie, finance etc. Specialiseren op 2 assen gaat nog, op drie is natuurlijk geen specialisatie meer.

Voorbeelden van componentisering: een softwareontwikkelaar gebruikt standard componenten van een derde of freeware. Nog een voorbeeld: de opmaak van af te drukken documenten zit niet meer in de programmatuur, maar gebeurt door een document manager.

Voor de business betekent di,t dat er altijd sprake is van meerdere leveranciers, soms dichtbij (intern of huisleverancier), vaak verder weg (een derde die de software levert, beheert en onderhoudt), maar steeds vaker “ergens”: in de cloud.

In Nederland kennen we al heel lang de term vraagorganisatie. Looijen en Delen noemden het Functioneel Beheer, BiSL noemt het Business Informatiemanagement en gebaseerd op het Amsterdams Informatiemodel (het 9-vlaks model) wordt vaak gesproken over de IV-organisatie.

In rollen uitgedrukt ziet dat er als volgt uit:

Maar ook de term Regieorganisatie wordt gehanteerd. En dan wordt het verwarrend. Want is dat dan hetzelfde als vraagorganisatie? U voelt het antwoord al aan: nee.

Regie zit aan twee kanten: regie van de vraag en regie op het aanbod. Als de IT bij één partij is belegd of als de IT overzichtelijk is dan kun je dat als vraagorganisatie (business informatie management) nog wel zelf aansturen. Als de IT ingewikkeld is en/of bij veel partijen is uitbesteed, die zich ook nog eens buiten je gezichtsvlak bevinden (cloud, leveranciers van leveranciers) dan loop je tegen het integratievraagstuk aan. Dat is een heel technisch issue, waar de gemiddelde vraagorganisatie geen verstand van heeft en ook niet van hoeft te hebben. Het speelt dan ook in de rechterkolom van het 9-vlaksmodel en niet, zoals ik vaak lees en hoor, in de middelste kolom.

Voor de regie op de aanbodkant bestaan 3 oplossingen: (1) de interne IT-afdeling pakt dit op, (2) één der sourcing-partijen pakt dit op (werkt dus niet in de cloud) of (3) je neemt daar een derde voor in de arm. Voor de hand ligt om te starten met optie (1).

Voor de IT-afdeling betekent dit een verschuiving van uitvoering naar integratie en regie (op de buitenkant). Voor de vraagorganisatie BIM blijft de situatie relatief gelijk: integratie en regie op de vraagkant en opdrachtgever richting de interne IT-leverancier danwel de regiepartner.

In het BiSL-boek en voorafgaand in het ASL-boek, spraken we altijd al over het Serviceteam (zie par. 2.2 van BiSL-boek). Het serviceteam is dus de regiepartij aan de aanbodkant. De invulling van het serviceteam is situationeel: zie de genoemde 3 opties.

De BiSL-processen beginnen in de wereld van professionals op het gebied van Business Informatiemanagement gemeengoed te worden. Daarbij worden natuurlijk niet alle processen als even zwaarwegend of belangrijk ervaren. Het BiSL-proces dat misschien wel het minste in de belangstelling staat is Beheer Bedrijfsinformatie. Naar mijn idee is deze ondergeschoven positie niet terecht en zelfs gevaarlijk voor de continuïteit van de bedrijfsvoering.

Ik snap dat ik, als mede-auteur van het BiSL-framework, de schijn tegen heb, maar ik vind een invoering van BiSL á la lettre absoluut niet nodig. Sterker nog, het is mijn stellige overtuiging dat een dergelijke benadering in de praktijk helemaal niet werkt. Waar ik wel volledig achter sta, is de noodzaak om aan elk van de BiSL-processen de juiste aandacht te besteden. En Beheer Bedrijfsinformatie is daarbij een belangrijk proces om aandacht aan te besteden. Op uitvoerend niveau is dit proces het centrale proces waarin de zorg voor de gegevens en informatie centraal staat. In feite is de wijze waarop deze zorg opgepakt wordt, bepalend voor de informatiekwaliteit binnen de organisatie. En de informatiekwaliteit blijkt in de praktijk meer en meer een sterk bepalende factor voor het resultaat van de bedrijfsprocessen! Foute beslissingen in de uitvoering of de besturing van het bedrijfsproces of het beleid voor de bedrijfsvoering blijken heel vaak terug te voeren op informatie die tekort schiet. Dat betekent, dat de informatiekwaliteit blijkbaar niet voldoende was.

En daar komen we meteen op een heikel punt voor gegevens- en informatiekwaliteit: hoe bepalen we de benodigde informatiekwaliteit en de achterliggende gegevenskwaliteit. En hoe borgen we die gewenste kwaliteit? Vaak wordt de oplossing voor gegevenskwaliteit gezocht in de inzet van tooling en geautomatiseerde functionaliteiten binnen applicaties. Minstens zo vaak blijken deze maatregelen niet goed doordacht en ook niet te passen op datgeen wat de organisatie nodig en gewenst vindt. De menselijke invloed blijkt toch altijd weer cruciaal voor de gegevenskwaliteit.

Aan de ene kant heeft dit te maken met de wijze waarop de eindgebruikers de informatievoorziening gebruiken en vullen met gegevens. Gebruikers die er met de pet naar gooien veroorzaken slechte gegevensinvoer en veroorzaken daarmee ondermaatse gegevenskwaliteit. Aan de andere kant is de manier waarop het lijnmanagement de organisatie bestuurt ook van cruciaal belang voor de gegevenskwaliteit. Ingegeven door de noodzaak om in te spelen op wijzigende omstandigheden, komt lijnmanagement nogal eens met wisselende ideeën over de bedrijfsvoering en veroorzaakt daardoor nogal eens ondermijning van de eigen ingestelde kwaliteitsmaatregelen. Voor puristen op het gebied van informatiekwaliteit is dit onverteerbaar. En ook de functioneel beheerder die zich tot het uiterste inspant om problemen met de gegevenskwaliteit op te lossen, is dit vervelend en verwarrend. Maar voor de gebruikersorganisatie en hun lijnmanagement is dit de praktijk van alledag. Men moet voldoende bewegingsruimte hebben om de beoogde organisatieresultaten te kunnen behalen onder wijzigende omstandigheden. Deze wijzigingen kunnen worden ingegeven door ontwikkelingen op de markt, de politiek, consumentengedrag, technologie et cetera.

Het is voor de gebruikersorganisatie überhaupt moeilijk om kaders te stellen aan informatiekwaliteit. Voor het lijnmanagement is bepaalde bewegingsvrijheid in de wijze van bedrijfsvoering noodzakelijk waardoor een fraaie, geïmplementeerde workflowoplossing ineens als te knellend wordt ervaren. Management wil met gegevens bepaalde doelen bereiken en heeft daardoor behoefte aan specifieke ontsluiting en presentatie van gegevens. En voor de eindgebruikers is de manier waarop met gegevens of gegevensinvoer wordt omgegaan vaak niet het gevolg van onzorgvuldig werk, maar werken conform de gewenste werkwijze die nodig is voor het bedrijfsresultaat. Begrip en borging van deze menselijke maat en ondersteuning om de noodzakelijke informatiekwaliteit binnen de organisatie vast te stellen en te bereiken is een belangrijk onderdeel van het BiSL-proces Beheer Bedrijfsinformatie. En daarmee is het belang van Beheer Bedrijfsinformatie voor de informatiekwaliteit en daarmee voor de continuïteit van de bedrijfsvoering aangetoond!

Als u wilt reageren naar aanleiding van deze blog, stuur dan een e-mail naar frank.van.outvorst@thelifecyclecompany.nl.

Even wat statistieken uit de Automatisering Gids (AG) van 18 juli 2013:

• Op de vraag “is het gebruik van mobiele toepassingen business- of IT-gedreven?” antwoordt 28,8 % van de respondenten: business gedreven, 19,2 zegt: business en IT en slechts 4,8% geeft aan: IT-gedreven (42,4% gebruikt geen mobiele apps). (Bron: Keala Research in opdracht van Sogeti, bij 125 grote organisaties). De conclusie van het onderzoek is: de business staat aan het roer. AG concludeert: mobiel werken en mobiele toepassingen zijn hoofdzakelijk business-gedreven. IT zal op deze terreinen dus een andere rol moeten spelen dan ze gewend is.
• Uit het zelfde onderzoek komt naar voren dat in 40,8% van de gevallen IT verantwoordelijk is voor de apps en in 29,6 % is het de business (17,6 geeft aan: niemand specifiek en 10,4 % geeft aan: algemeen management (wat is het verschil??). AG concludeert: de verantwoordelijkheid voor de apps is ongeveer even vaak bij de business belegd als bij de IT-afdeling.
• 30% van de respondenten geeft aan dat de overgrote meerderheid in hun organisatie 75 tot 100% van de medewerkers regelmatig mobiel werkt. In de helft van de organisaties in Nederland werkt minstens 50% van de medewerkers regelmatig online.
• 48% van de IT-managers staat positief tegenover bring-your-own-device (BYOD) en slechts 12% negatief

Wat zegt dit allemaal? Vooral dat de bepalende rol van de IT-afdeling terugloopt. Niet IT bepaalt wat nodig is of waaruit gekozen mag worden, maar de business bepaalt wat nodig is. Anders gezegd: er vindt een overgang plaats van aanbod-gestuurd naar vraag-gestuurd, zelfs als het gaat om basis IT-voorzieningen. Voor Business informatiemanagement (BIM oftewel: Functioneel Beheer) is dit wel een uitdaging: ook al wil je het misschien niet, je rol wordt steeds belangrijker, want BIM zal hier zeker een rol in spelen. Al is het alleen al omdat de BIM-er zich af zal moeten vragen: wat betekent dit, wat is mijn rol/taak/verantwoordelijkheid? Wat is ons beleid op het gebied van BYOD/CYOD (choose-your-own-device), wat betekent dit voor ons beveiligingsbeleid, wil ik zelf apps gaan selecteren en aanbieden of promoten (of zelfs: laten ontwikkelen) of laat ik het gebeuren?

Overigens staat in dezelfde AG een artikel over de beveiliging van laptops en smartphones. Hiervoor geldt hetzelfde: het lijkt misschien alleen een IT-probleem, maar het is zeker ook een probleem van BIM.

Reacties graag naar rene.sieders@thelifecyclecompany.nl

<

In mijn vorige blog heb ik geschreven over de toegevoegde waarde van BiSL voor Big Data. Ik heb daarbij aangegeven dat een deel van de toegevoegde waarde vanuit BiSL ligt in de zorg voor de gegevens en de gegevenskwaliteit. Binnen BiSL is hiervoor het proces Beheer Bedrijfsinformatie gedefinieerd. Het is voor de hand liggend dat dit BiSL-proces en Big Data sterk met elkaar verweven zijn.

Inmiddels ben ik gestart met het schrijven van een boek over het BiSL-procescluster Gebruiksbeheer. Dit boek gaat deel uitmaken van een set van boeken die voor het BiSL-framework (waarin het WAT staat beschreven) invulling geven aan de vraag HOE je de door BiSL gedefinieerde processen kunt uitvoeren. Een van de processen binnen Gebruiksbeheer is het proces Beheer Bedrijfsinformatie. Dit proces gaat onder andere in op de zorg voor het gebruik en de kwaliteit van de gegevens in de informatiehuishouding van een organisatie. Big Data zal voor de gegevenskwaliteit wel het nodige betekenen.

Ik moest hier eerder deze week aan denken, toen de brandstofmeter in mijn auto in de rode zone was gekomen. Tijd om een tankstation op te zoeken. En dan liefst een niet al te duur tankstation. Maar ja, waar is de brandstof voordelig en waar niet? Hiervoor heeft een vriend mij niet zo lang geleden een handige app voor op mijn smartphone aangeraden. Op deze app kun je zien welke tankstations zitten in de buurt van je actuele locatie en wat de brandstofprijs daar is. Heel handig! Nu vertrouwt mijn vriend altijd blindelings op alles wat hij binnenkrijgt via zijn app-jes. Maar ik ben zo eigenwijs dat ik daar niet altijd op vertrouw. Helaas heb ik de laatste tijd af en toe wat tijd over. En dan kan ik soms de verleiding niet weerstaan om toch eens de gegevens van mijn app-je te ijken aan de pompprijzen. En wat is de uitkomst? De app heeft niet altijd gelijk! Sterker nog, het lijkt er soms op, dat de prijzen van de app ’s-ochtends vaker kloppen dan later op de dag, wanneer de pompprijzen in de loop van de dag een beetje omhoog gegaan zijn! Waarschijnlijk gewoon toeval of een tijdvertraging waardoor de gegevens in het app-je nog niet up-to-date zijn. Of zou er toch een slimme truc achter zitten? Het lijkt mij, dat niet veel bestuurders nog door zullen rijden naar een ander tankstation, nadat hun app-je hen naar een bepaald tankstation heeft gestuurd, zelfs als de prijzen daar (inmiddels een beetje) hoger zijn. De kwaliteit van de gegevens in mijn app-je heeft in dit voorbeeld dus een direct financieel gevolg voor mij.

Waarom breng ik dit consumentenvoorbeeld nu in verband met Big Data en het BiSL-proces Beheer Bedrijfsinformatie? Welnu, het is niet altijd even duidelijk hoe betrouwbaar externe data zijn. En zoals uit eigen onderzoek is gebleken, zijn niet alle externe data op ieder moment even betrouwbaar als je eigenlijk zou willen. Het is belangrijk, om met dit gegeven rekening te houden als je (als organisatie) vorm geeft aan gegevensgebruik en bezig gaat allerlei gegevens –ook vanuit externe bronnen- met elkaar te verbinden. Het is niet alleen noodzakelijk om goed te weten waarvoor je alle gegevens wilt gebruiken en op basis daarvan kwaliteitscriteria voor de eigen processen en gegevens te definiëren en te bewaken. Het is ook belangrijk, om te weten met welk doel externe gegevens worden verzameld, wat de kwaliteitsnormen en –maatregelen zijn voor dergelijke gegevenssets en ook wat het achterliggende business-model van de externe partij is om deze gegevens te willen delen.

Op basis van deze kennis is het mogelijk om gepaste maatregelen voor de eigen procesvoering en de eigen gegevenskwaliteit te nemen. Hopelijk worden onverwachte en ongewenste effecten (in mijn voorbeeld een hogere brandstofrekening) voorkomen. Het doel van informatievoorziening is immers te komen tot een beter organisatieresultaat en niet tot een verslechtering. Ook voor de in ontwikkeling zijnde boekenreeks waarin we allerlei instrumenten aanreiken om de BiSL-processen echt op te pakken en uit te voeren is dit de achterliggende gedachte. Vanzelfsprekend zal gegevenskwaliteit een belangrijk onderwerp zijn in het boek over het BiSL-cluster Gebruiksbeheer. Daarmee wordt ook een verdere invulling gegeven aan de toegevoegde waarde van BiSL voor Big Data.

Wil je reageren op deze blog? Stuur me dan even een mail: frank.van.outvorst@thelifecyclecompany.nl

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).