Blogisch!

Ik heb even een inleiding nodig om een punt te maken. Het komt nog maandelijks voor dat “een externe informatievrager” onze instelling verzoekt bepaalde informatie te leveren. Omdat we niet “op” onze eigen informatie “zitten” zijn we qua houding altijd bereid om te kijken wat iemand vraagt, waar het voor is en nog beter: de geleverde informatie op te nemen in onze informatievoorziening. Een externe vrager is vaak een “stakeholder” waar je verantwoording aan af te leggen hebt. Zoals de inspectie, accountants, gemeentes, convenant-partners, brancheorganisaties, samenwerkingsverbanden en regionale partners etc. Soms gelden wettelijke verplichtingen, soms gelden afspraken waar we ons zelf aan houden, omdat we als instelling ervoor kiezen om samen te werken.

Toch kleven er een aantal grote nadelen aan:

• Dezelfde externe vrager kan jaarlijks zijn definities aanpassen of zijn totale informatiebehoefte herzien.
• Elk antwoord roept nieuwe vragen op. Dat geldt zeker voor geleverde informatie. Standaard wordt de grens opgezocht van de geleverde informatie, om vervolgens weer andere vragen te stellen. Je zou kunnen redeneren dat dat is om analyses te maken. Maar het komt over alsof de geleverde informatie nooit genoeg is.
• Verschillende partijen vragen op hetzelfde terrein net iets anders, op net andere tijdstippen. Externe partijen bundelen hun overeenkomstige vraag niet. Vanuit het perspectief “WIJ vragen, U draait…”. Voor je het weet kun je als informatie-diskjockey weer met je turntables aan de gang in Excel …
• Het passeert volledig de koninklijke weg: er wordt vanuit gegaan dat wat gevraagd wordt ook altijd leverbaar is. Maar informatie is altijd afhankelijk van data, die op zijn beurt ook weer product moet zijn van een registratieproces. Dus niet beginnen met “Ik wil gewoon weten…“

Het gevolg van dit alles is een niet-coherente informatievoorziening waarin het aandeel ad-hoc antwoorden veel te groot is. Nu zijn we natuurlijk niet de eerste die dit signaleren. Zoals Marcel Laks al eens onder woorden bracht: “Laat het MBO zich ringeloren?”. Één van de tips was toen om als ROC’s samen te werken en als eenheid naar externe partijen toe op te treden. Dat gebeurt op beperkte schaal ook al. Wij werken hier ook aan mee. Maar het zou nog een stapje verder kunnen gaan. Hoe?

Door de informatielast om te keren. Hoe ziet zo’n omgekeerde informatielast eruit? (Heb de term overigens niet zelf verzonnen, komt van een collega ) Omgekeerde informatielast gaat er vanuit dat de eigen informatievoorziening in principe voldoende is om externe vragen te kunnen beantwoorden. Bij nieuwe vragen wordt hier eerst naar verwezen. Pas als het echt niet voldoende is, kan er verder nagedacht worden. De omkering komt tot stand door op de vraag “Kunt u leveren…?” de wedervraag te stellen “Kunt u zoeken…?”.

Wat is er nodig om met deze gepaste arrogantie aan de slag te gaan?

• Een InformatiePortfolio: een beheerd overzicht van alle informatie die we als instelling op leveren. Een portfolio bevat niet alleen de informatie zelf, maar ook alle metadata zoals definities, criteria, berekeningen, versies en documentatie.
• Een volwassen en rijpe informatievoorziening die dit portfolio vult. Dit heeft intern heel wat voeten in aarde.
• Toegankelijkheid en transparantie: Wil je kunnen verwijzen naar een InformatiePortfolio dan moet deze makkelijk bereikbaar en doorzoekbaar zijn.

Het is nu nog te vroeg voor een technische uitwerking hiervan in een portal. Een InformatiePortfolio kan alleen onder architectuur goed worden uitgewerkt. Maar we hebben een begin!

Dit ligt het meest voor de hand met database gebaseerde applicaties. Maar generieker klopt het ook. Het viel me op aan hoe de vraag gesteld wordt, vòòr articulatie dan.

Een willekeurig persoon vraagt: “Ik wil gewoon in pakket X … kunnen”. Waarbij … de gewenste functionaliteit voorstelt.

Een andere willekeurig persoon vraagt: “Ik wil gewoon weten hoeveel … “. Waarbij … de gewenste informatie voorstelt.

Als iemand zegt, dat hij in Paint een foto zo willen kunnen spiegelen, wat natuurlijk kan, dan is dat een verzoek om functionaliteit. Tegelijk is het een verzoek om informatie: geef me de kleurwaardes op coördinaat x,y en wissel vervolgens de waarde van x en y om. In dit voorbeeld een beetje gechargeerd, maar het geldt nog meer voor informatie opgesloten in administratieve systemen en sociale sites.

Dit is voor mij de reden dat het logisch is om in een organisatie Functioneel Beheer onder Informatiemangement te plaatsen. Naast alle redenen die frameworks als ITIL en BiSL bepleiten.

Overigens is er nog iets tricky aan bovenstaande vragen: Ze beginnen allemaal met “gewoon”. De vraagsteller kan dit zo noemen om allerlei redenen. Hij/zij vindt zijn vraag een logisch verzoek of een makkelijk verzoek.

Na articulatie blijkt vaak dat zijn vraag niet logisch is, als het probleem dat het moet oplossen er niet mee opgelost kan worden. Of je krijgt inzicht (van data naar kennis) in iets, maar je kunt het niet gebruiken voor je eigen probleem. Of het lijkt makkelijk, maar het blijkt eisen te stellen aan het registratieproces van de data.

Doet me denken aan de Office-functionaliteit: “Waarom is Office zo groot? Ik gebruik maar 20% van de functionaliteit.” Klopt! Maar ieder individu gebruikt een verschillende 20%…

Zo is het met informatiebehoefte ook. Een nieuw element binnen de informatievoorziening zal altijd maar voor een beperkte groep zinvol zijn. Een “gewone” vraag voor de een is een “exotische” vraag voor de ander.

Is dit te tackelen? Jazeker, veel BI wordt opgehangen aan Balanced Score Carding. Zodat je elementen uit de bestuurlijke agenda (wat willen we?), koppelt aan succesfactoren (welke succesen dragen bij aan onze doelen?) en prestatie-indicatoren (waaraan zie je dat je succes hebt?). Deze laatsten zouden kunnen worden opgelevert vanuit de systemen.

Vooralsnog kanaliseer je hier informatiebehoefte mee op strategisch/tactisch niveau. Op operationeel niveau zou het ook mogelijk moeten zijn om informatiebehoeften te hangen aan bovenstaande hiërarchie. Echter: strategisch en operationeel niveau zijn nog al eens 2 compleet verschillende werelden…