In het beheer van een informatiesysteem kennen we de klassieke rollen van functioneel-, applicatie- en technisch beheer. In de praktijk komt hier steeds vaker een vierde rol bij: content beheer. Laten we die dan ook expliciet maken en de erkenning geven die het nodig heeft, om zo de keten van systeem naar gebruiker compleet te maken.
Van Looijen kwam in de jaren tachtig met het model voor de rolverdeling bij het beheren van informatiesystemen dat we nog veel gebruiken. Hij maakte onderscheid tussen functioneel beheer (fb), applicatiebeheer (ab) en technisch beheer (tb) om duidelijk te maken welke verschillende invalshoeken komen kijken bij het beheer van een systeem. Kort door de bocht bewaakt het functioneel beheer de functionaliteit van het systeem en ondersteund de gebruiker, het applicatiebeheer realiseert de benodigde functies of repareert ze waar nodig en het technisch beheer zorgt er voor dat de servers en het netwerk hun werk doen.
In de basis gebruiken heel veel organisaties dit systeem nog steeds. En om misverstanden te voorkomen: daar is niets mis mee. Het is een zeer bruikbare indeling om de taken in te delen en vindt je dan ook terug in de facto standaard frameworks als ITIL, BiSL en ASL.
Veranderende rollen
In het model van Van Looijen vertegenwoordigt aan de ene kant het functioneel beheer de vraag en aan de andere kant het applicatiebeheer én technisch beheer het aanbod. Van oorsprong lagen deze rollen allemaal binnen de ict-afdeling. Ervaring leert dat met name het functioneel beheer steeds meer samen met de business wordt gedeeld. De eindgebruiker weet immers wat hij nodig heeft. Daarom liggen steeds meer functioneel beheertaken bij de business en de andere bij de ict-afdeling. De functioneel-beheerder bij de ict-afdeling wordt hiermee steeds meer de regisseur tussen de business en de andere twee beheerrollen (ab en tb). Dit wordt nog eens versterkt door het uitbesteden van het technischbeheer en applicatiebeheer, waarbij de functioneel-beheerder die externe partijen inhoudelijk zal moeten aansturen.
Al het voorgaande gaat over het systeem zelf, maar niet over de inhoud van het systeem. Wie houdt in de gaten of de gegevens kloppen en compleet zijn? Technisch beheer kan vertellen of het systeem naar behoren draait, applicatiebeheer of functies correct werken en functioneel beheer of het aansluit op de behoeften van de organisatie. Meestal werd ook aan functioneelbeheer gevraagd om de inhoud van het systeem in de gaten te houden. Op afstand is dat best moeilijk. Pas nu het functioneelbeheer steeds meer in de business zelf ligt, lukt dat steeds beter.
Toevoegen: contentbeheer
Ik denk dat het nog beter is om een rol voor contentbeheer te onderscheiden naast die van functioneelbeheer. Deze extra rol komt in zijn geheel in de business te liggen. Het contentbeheer kan dan naar een vakinhoudelijk specialist voor dat systeem en het functioneelbeheer kan zich richten op het functioneren van het systeem. Je zou daarbij kunnen overwegen om de contentbeheerder ook de inhoudelijke gebruikersondersteuning te laten vervullen, hoewel dat in de praktijk erg afhankelijk is van de betrokken vakinhoudelijk specialisten, die daar dan wel didactisch toe in staat moeten zijn.
Doordat je deze rol expliciet maakt, kan deze ook expliciet worden belegd. Dit vraagt immers tijd, moeite en aandacht. Daarnaast wil je ook aan de organisatie duidelijk maken dat deze rol bestaat en de erkenning geven die deze nodig heeft.
Voorbeeld
Zelf werk ik veel aan DMS-projecten. Daarbij zie je dit effect ook optreden. De functioneelbeheerder is druk in de weer met gebruikersbeheer, change requests, gebruikersondersteuning of de aansturing ervan. Hij kan je bijvoorbeeld prima vertellen wat het verschil is tussen een ‘documentsoort’ en een ‘trefwoord’ (in de praktijk lastiger dan je zou denken…).
Maar het hoofd DIV of recordmanager is uiteindelijk verantwoordelijk voor het documentbeheer binnen de organisatie. Hij weet welke documentsoorten in de processen worden gebruikt en kan inschatten of een dossier compleet is of niet. De functioneelbeheerder niet. Door de recordmanager (en zijn team) de verantwoordelijkheid te geven voor de inhoud van het systeem en de toepassing in de organisatie kan de laatste slag worden gemaakt van systeem naar eindgebruiker. Dit natuurlijk in nauwe samenwerking met de overige beheerders.
Harmen Lindeboom , senior adviseur bij M&I/Partners
Harmen, zeer valide argumenten om de content beheerder rol te definiëren en beleggen. Deze rol is in vele organisaties niet belegd en leidt tot onvolledige, onjuiste, niet tijdige en kwalitatief slechte gegevensvorming en verstrekking. De makers en gebruikers voelen zich onvoldoende verantwoordelijk voor het onderhouden van de kwaliteit en volledigheid van de informatie.
Ik vraag me wel af of het wel werkbaar is om de verantwoordelijkheid van de informatie alleen bij de DIV/recordmanager te beleggen. Ik denk wel dat de regierol bij de DIV/record/informatiemanager belegd moet worden, maar dat de verantwoordelijkheid voor volledigheid, juistheid en juiste kwaliteit dichter bij de specialisten (de makers en gebruikers van de informatie) belegd moet worden.
@Harmen: zou je nog even willen toelichten wat je precies bedoelt met de inhoud van het systeem?
@Marianne – helemaal gelijk. Het contentbeheer moet zo dicht mogelijk bij de eindgebruiker liggen. Echter, als een groep ergens voor verantwoordelijk is, dan komt het veel voor dat niemand zich verantwoordelijk voelt. Dus moet er iemand wakker liggen als het niet gebeurt en de regie houden. In het geval van het DMS lijkt me dit dus bij DIV (oid) te liggen, maar nooit zonder de input van de rest van de organisatie. Documentbeheer is géén DIV-feestje.
@Hans: ik bedoel de “gebruikersinhoud” van een systeem. De documenten in het DMS, de plaatjes in een beeldbank, de “grootboekregels” in het financieel systeem, etc. etc.
@Harmen. Als het gaat om de gebruikersinhoud heeft dat volgens mij niet direct met het beheren van (de functionaliteit van) informatie(voorziening)systemen te maken. Dat is ook de reden waarom ik je vroeg wat je er precies mee bedoelt.
In de business (dat geef je al aan) dient gebruikersinhoud vastgesteld en beheerd te worden. De benodigde functionaliteit, zowel voor dat beheer, alsook de voor de bewerking van de inhoud, wordt geleverd door informatievoorziening, via functioneel en technisch beheer.
Document management is daarbij volgens mij echt iets anders dan contentmanagement. Een DMS dient functionaliteit te bieden om de binnen de keten gebruikte of ontwikkelde documenten te kunnen aanmaken, opslaan, bewerken en opvragen. De content van die documenten moet bewaakt en gecontroleerd worden door (een specialist uit) de business (zoals hierboven besproken). Kortom: het document zelf (een NAW formulier bijvoorbeeld), de functionaliteit om het aan te maken te bewerken, op te slaan en weer op te vragen en de inhoud, of content, van dat document (de NAW gegevens) zijn drie verschillende dingen en vragen om drie verschillende vormen van beheer: documentbeheer, gegevensbeheer en functioneel beheer. Voor de eerste twee zou je misschien één (business) contentmanager kunnen aanwijzen, voor de laatste kan dat naar mijn mening niet.
Dit verhaal illustreert naar mijn mening eens te meer hoe belangrijk het is dat de business haar (primaire en secundaire) processen beheerst en zelf weet aan te geven welke functionaliteit zij nodig heeft om gegevens in te voeren, op te slaan, te bewerken en weer op te vragen. Over de inhoud gaat de business nog altijd zelf. De functionaliteit en de werking daarvan wordt beheerd door FB en TB.
Het is zeker goed e.e.a. onder de aandacht te brengen.
@Harmen,
Binnen een conventioneel SAP ERP Systeem zijn is de “gebruikersinhoud” te verdelen in : master data en transactie data.
Verder is er content in de vorm van : Portal Content en Webshops.
Traditioneel gezien is het wijzigen van financiele master data (bijvoorbeeld grootboek) slechts voorbehouden aan daarvoor geauthoriseerde gebruikers (boekhouder, financiele specialisten). Het wijzigen van sales gerelateerde master data (bijvoorbeeld klant gegevens) is voorbehouden aan sales personeel, en de HR data aan HR medewerkers. Het wijzigen van Portal en Webshop content is wat meer technisch van aard en vereist, behalve de juiste authorisaties, ook een compleet andere skill-set.
Dergelijke authorisaties zijn er onder andere om functiescheiding te bewerkstelligen en fraude tegen te gaan.
Contentbeheer is een onderdeel van de taak van de eindgebruikers van het systeem. Als niemand zich daar verantwoordelijk voor voelt, dan ontbreekt er een essentieel businessprocess.
Vooropgesteld dat je een persoon zou kunnen vinden die , zowel technisch als semantisch, kan omgaan met het muteren van alle vormen van content, is het niet verstanding om die persoon, vanuit het oogpunt van functiescheiding en beveiliging, alle content dan ook maar te laten wijzigen.
De oplossing ligt in dat geval niet in het creëren van een nieuwe functie, maar in het creëren van de ontbrekende business processen.
Niet tijdige of kwalitatief slechte informatievoorziening is meer een organisatorisch probleem van achterhaalde processen zoals een gedigitaliseerde papierstroom met slechte archivering en een technisch kennisgebrek dan een beheerkwestie. Als ik me niet vergis heeft van Looijen ook een taxanomie gemaakt om de organisatorische problemen als gevolg van heterogeniteit en evolutie van netwerken te ondervangen en waarin nog meer lagen benoemd werden. De facto framewerken als ITIL, BiSL en ASL schieten namelijk vaak tekort door abstracte niveau van beschrijven, het zijn studeerkamer gedrochten waardoor beheer in zijn voegen piept en kraakt door de digitale versnelling van de laatste jaren.
Zo wordt de digitale informatievoorziening vooral aangestuurd op incidenten (piepsysteem) waardoor governance (kraken) meer geluk dan wijsheid is. NAW-gegevens zijn bijvoorbeeld geen content maar privacygevoelige gegevens, de wijze waarop omgegaan wordt met dit soort informatie is vaak tenenkrommend. En in de drang om alles vast te leggen worden dossiers ook nog weleens samengesteld uit bronnen die voor heel andere doeleinden bedoeld zijn. Een content beheerder klinkt dus meer als een extra pionnetje op het bord, het afschuiven van de verantwoordelijkheid zoals KJ ook al zegt.
Contentbeheer, ja graag! En wel dicht bij de bron. Het beheermodel Looijen gaat over informatievoorziening waar het het beheer van informatiesystemen betreft. Platform en infrastructuur, dus geen inhoud. Dat is de kracht van het model: ongeacht waartoe het informatiesysteem dient, kan het conform Looijen beheerd worden.
Content is product, output van een proces. Niet noodzakelijkerwijs als inhoud in een document, maar liever als omschreven entiteit, zonder vaste vorm/presentatie. Om content te kunnen produceren, is andere content nodig, input. De producent van content doet dit op geprefereerde wijze, al dan niet met gebruik van meer of minder (beheerde) informatiesystemen.
De producent (proceseigenaar) is verantwoordelijk voor input, throughput en output. Wet- en regelgeving volgend afspraken maken dus met verantwoordelijken/eigenaren/producenten van de benodigde input; wat mag in de uitvoering gebruikt worden, aan welke voorwaarden dient de producent te voldoen tijdens en na gebruik van de input.
Afspraken over de throughput, oftewel het informatiesysteem (functioneel, applicatie en technisch beheer).
En de belangrijkste: welke eisen stelt de producent aan (her)gebruik van zijn product? Want zijn product ziet hij toch graag gebruikt worden door anderen, als input. Contentbeheer bestaat er dan vooral uit deze context juist te beschrijven. Voor te schrijven zo u wilt. Wie mag aan de productverzameling toevoegen, wie mag ze uitlezen, wie mag ze aanpassen, wie mag er uit verwijderen? Hoe? Van waar? Welk gedeelte van geproduceerde content stelt de eigenaar open voor (her)gebruik? Geef het maar aan als creator van het product, in zoverre je ook eigenaar bent en niet gebonden bent aan overorven voorwaarden in het gebruik, of exclusief recht van de opdrachtgever.
@Harmen: functioneert het contentbeheer dan inderdaad als vierde eenheid? Direct gelinkt aan de business kant weliswaar. Gelinkt aan al die productregistraties (besluit, vergunning, foto, factuurregel, persoon, adresseerbaar object, maatregel van bestuur, etc.), ongeacht verschijningsvorm, maar wel op record niveau portabel.
Allereerst dank voor jullie bijdragen, ga ik zeker meenemen in eventuele vervolgen.
Volgens mij zijn we het er over eens dat de aandacht voor de content van het systeem nodig is en wel uit de business. Als de businessprocessen op orde zijn dan zou de vraag kunnen zijn of er wel behoefte is aan een extra beheerrol. Leuk om te zien dat hier toch ruimte is voor verschillen.
Zelf denk ik dat niet altijd even duidelijk de grens te trekken is, met name omdat lang niet alle businessprocessen altijd op orde zijn. Het expliciteren van dat contentbeheer daarbij kan helpen. Misschien moet ik eens onderzoek doen naar de samenhang met het “maturity level” van organisaties.