Professor Maarten Looijen heeft al weer een tijdje geleden de driedeling technisch beheer, functioneel beheer, applicatiebeheer bedacht. Inmiddels hebben we de termen een beetje aangepast en spreken we over IT-infrastructuurmanagement (IT-IM) , applicatiemanagement (AM) en business-informatiemanagement (BIM). Hoewel niet iedereen het daarmee eens is, zeggen velen ook: ITIL is het servicemanagement framework voor IT-IM. Na ITIL zijn ASL ontwikkeld als model voor AM en BiSL voor BIM. Maar mij bekruipt af en toe het gevoel dat we toch nog iets missen. Wordt het tijd voor CSL?

Nog niet zo lang geleden waren bestanden en databases één-op-één gekoppeld aan een applicatie. Daarom is het beheer en onderhoud van de datastructuren ook logischerwijs onderdeel van AM (en dus ASL). Verder zorgt IT-IM o.a. voor het opbouwen en bewaren van de bestanden en ziet BIM toe op de eisen en inhoud. Prima! Maar tegenwoordig zie je dat bestanden en data een geheel eigen leven leiden, los van die ene applicatie. Een database is niet meer één op één gekoppeld aan een applicatie. In ITIL en ASL hangen data en bestanden er maar een beetje bij en het belang van data groeit.

De reden voor het ontwikkelen van ASL naast ITIL was omdat het onderwerp “beheer en onderhoud van software” in ITIL niet goed uit de verf kwam. Het onderhouden van software is een ander vak dan het beheren van de technische productie infrastructuur. Maar hetzelfde geldt eigenlijk voor data. Medewerkers van organisaties brengen hun eigen Apps en devices mee en gebruiken de data in hun eigen omgeving. Bewegingen als Cloud, Smart devices, Apps en Big Data hebben geen duidelijke plek in de 3 beheerdomeinen van Looijen.

Mijn gevoel: het wordt tijd voor CSL (Content Services Library). Wie A(SL) en B(iSL) zegt, moet ook C(SL) zeggen.

Wie ideeën heeft melde zich rene.sieders@thelifecyclecompany.nl

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.