Deze week raakte ik in een discussie over Raci matrices bij het inrichten van beheer. Raci is een hulpmiddel dat gehanteerd wordt om de rollen en verantwoordelijkheden van personen die bij een project of lijnwerkzaamheden betrokken zijn weer te geven. Op de horizontale as de namen van de personen of de functionele rollen, en op de verticale as de op te leveren resultaten, betrokken processen of activiteiten.
Raci's zijn erg handig als je beheerprocessen aan het inrichten bent. Wat ik in de discussie bracht was een toepassing waarbij je Raci inzet om de verantwoordelijkheden per beheerobject in kaart te brengen. ‘Beheerobject' gebruik ik om componenten van een informatiesysteem aan te duiden waar je verantwoordelijkheid over kunt nemen. Bijvoorbeeld een dbms, een database-schema, een module van een applicatie, een script, een gebruikershandleiding. Mijn model kent vier kolommen:
– Beheerobject
– Functioneel beheer
– Applicatiebeheer
– Technisch beheer
Met in de rijen de beheerobjecten en in de FB/AB/TB-cellen de RACI verantwoordelijkheden plus de verantwoordelijke. Bijvoorbeeld R:Roel, A:Anton, C:Clara, I:Ingrid. Is dus eigenlijk een driedimensionale Raci.
Het niveau van ‘beheerobject' is zelf te bepalen. Bij één organisatie heb ik de verschillende groepen gevraagd om een (lange) lijst te maken van alle voorkomens van hun beheerobjecten, dus alle applicatiemodules, databasescripts et cetera. Op artefactniveau dus. En vervolgens elkaars lijsten op overlappingen en gaten te onderzoeken. De meerwaarde ervan is dat je het ergens over hebt in plaats van hoog over alles aan te vliegen. Het is dan erg gedetailleerd en je krijgt er wel hoofdpijn van maar dat voorkomt buikpijn verder op in het traject, want eerder of later moet je toch duidelijk hebben wie waarover gaat.