Herkenbaar dilemma?
Komende week is het weer zover. De inhoud van de volgende sprint voor het organisatie brede back-office systeem gaat weer bepaald worden. Met een overvolle backlog is dat altijd een flinke uitdaging. Met de schaarse ICT middelen waarover we beschikken moeten we de wensen van drie belangrijke afdelingen zien te prioriteren. En niet alles is te realiseren; we moeten keuzes maken. De zaken die afvallen schuiven dus door naar de volgende release. Een moeilijke opgave. Zeker wanneer er meerdere belangen mee gemoeid zijn. De oplossing lijkt simpel: de productowner als gedelegeerd systeemeigenaar bepaalt toch? De literatuur omschrijft de applicatie- of systeemeigenaar als een persoon die bepaalt wat er met de software moet gebeuren en hoeveel capaciteit er in gestoken mag worden.
Maar wie is nu eigenlijk de systeemeigenaar? Wil de echte systeemeigenaar opstaan?
Eigenaarschap niet geregeld
In de praktijk komt het regelmatig voor dat een applicatie meerdere bedrijfsprocessen ondersteunt. De verantwoordelijkheid over deze bedrijfsprocessen ligt dan bij diverse organisatieonderdelen. Maar bij wie is het systeemeigenaarschap neergelegd? Vaak is het systeemeigenaarschap formeel niet geregeld en is er onduidelijkheid over de prioritering van de gewenste veranderingen. Dit kost onnodige tijd en levert frustratie op, met als gevolg dat functionaliteit niet of te laat wordt opgeleverd. Dit kan je voorkomen door vooraf duidelijk af te spreken wie eigenaar is van de applicatie.
Maar hoe bepaal je wie de eigenaar is? En is daarmee het prioriteringsprobleem opgelost?
Meerdere opties
In een dergelijke situatie is het niet eenvoudig om het eigenaarschap te bepalen. Wat is de juiste keuze? Op welke wijze wordt het eigenaarschap daadwerkelijk geaccepteerd? Ik schets hierbij een aantal mogelijkheden uit de praktijk.
- Optie 1: Eigenaarschap op basis van aantal gebruikers
Bij deze optie bepaal je het eigenaarschap op basis van kwantitatieve gegevens. Het voordeel is dat het op deze manier vrij eenvoudig te bepalen is. Het nadeel is echter dat de voorgenomen eigenaar mogelijk te weinig business belang heeft om zich als eigenaar op te werpen. Deze optie valt wat mij betreft af.
- Optie 2: Eigenaarschap op basis van het aantal wijzigingsverzoeken
De manager van het organisatieonderdeel met het hoogste aantal verzoeken tot wijziging wordt bij deze optie de systeemeigenaar. Schijnbaar heeft hij veel belang bij het systeem door het hoge aantal wijzigingen. Ook dit is op basis van de kwantitatieve gegevens eenvoudig te bepalen. Bij deze optie kan een perverse prikkel ontstaan die leidt tot het aanleveren van een onnodig aantal wijzigingsverzoeken. Dit is wat mij betreft ook geen goede optie.
- Optie 3: Eigenaarschap op basis van het zwaarste business belang
Bij deze optie kijk je naar de impact, de opbrengst en het risico van de bedrijfsprocessen. Deze aanpak komt wat mij betreft in de goede richting. In de praktijk is deze eigenaar ook bereid om het eigenaarschap op zich te nemen en de total cost of ownership te betalen.
Vandaar dat mijn stelling is: ‘Wie betaalt, bepaalt’. En wel om de volgende reden: het grote business belang van de eigenaar die wil betalen is invloed hebben op de applicatie. Bij onvoldoende invloed zal hij de pijn voelen en dat wil deze eigenaar natuurlijk zo veel mogelijk voorkomen. Zijn doel is tenslotte om business resultaten te behalen. Het systeemeigenaarschap is hiermee bepaalt, maar het probleem van de prioritering is nog niet opgelost.
Een praktische governance oplossing
Is het hebben van een allesbepalende systeemeigenaar in deze situatie praktisch werkbaar? Hoogstwaarschijnlijk niet. De ICT systeemeigenaar heeft primair de focus op de bedrijfsprocessen en niet op het beheren van de applicatie. Een praktische oplossing in dit geval is het inrichten van een board met belangrijke (gedelegeerde) stakeholders. Zij bepalen onderling de prioriteit waarbij de geschillen worden voorgelegd aan de (betalende) systeemeigenaar. Op deze manier worden alle belangen gewogen en is er uiteindelijk één duidelijke beslisser die de knoop doorhakt.
Staat jouw organisatie vaak voor dilemma’s met betrekking tot het inrichten van governance structuren?