Wil de echte ict-systeemeigenaar opstaan?

Komende week is het weer zover. De inhoud van de volgende sprint voor het organisatiebrede back-office systeem moet worden bepaald. De backlog is vol, de middelen zijn schaars en meerdere afdelingen hebben dringende wensen. Niet alles kan. Wat afvalt, schuift door naar een volgende release. Dat leidt tot discussie, frustratie en lastige keuzes.

‍

De oplossing lijkt op papier eenvoudig. De product owner bepaalt de prioriteit als gedelegeerd systeemeigenaar. In theorie klopt dat ook. In veel literatuur wordt de applicatie- of systeemeigenaar beschreven als degene die bepaalt wat er met de software gebeurt en hoeveel capaciteit daarvoor beschikbaar is.

‍

Maar wie is die systeemeigenaar eigenlijk?

In de praktijk ondersteunt één applicatie vaak meerdere bedrijfsprocessen. Die processen vallen onder verschillende organisatieonderdelen. Het eigenaarschap is dan formeel niet belegd, of slechts gedeeltelijk. Gevolg is onduidelijkheid over prioriteiten, vertraging in besluitvorming en irritatie bij zowel business als IT. Functionaliteit komt later dan gepland of helemaal niet.

‍

Dat is te voorkomen door vooraf helder af te spreken wie eigenaar is van de applicatie. Maar hoe bepaal je dat eigenaarschap op een manier die ook echt werkt?

‍

In de praktijk zie je verschillende benaderingen. Een eerste optie is het toewijzen van eigenaarschap op basis van het aantal gebruikers. Dat is eenvoudig te meten, maar zegt weinig over het daadwerkelijke businessbelang. De afdeling met de meeste gebruikers heeft niet per definitie de grootste verantwoordelijkheid of urgentie. Deze aanpak werkt zelden goed.

‍

Een tweede optie is eigenaarschap koppelen aan het aantal wijzigingsverzoeken. De afdeling die de meeste changes indient, krijgt het eigenaarschap. Ook dit lijkt logisch, maar kan een perverse prikkel creëren. Meer wijzigingsverzoeken indienen om invloed te krijgen, in plaats van omdat ze echt nodig zijn.

‍

Een derde optie kijkt naar het zwaarste businessbelang. Daarbij weeg je impact, risico en opbrengst van de processen die door de applicatie worden ondersteund. In de praktijk blijkt dit vaak beter te werken. De eigenaar die het grootste belang heeft, is ook bereid verantwoordelijkheid te nemen voor kosten en keuzes. Wie betaalt, bepaalt. Niet vanuit macht, maar vanuit betrokkenheid bij het resultaat.

‍

Toch lost ook dit niet alles op. Eén allesbepalende systeemeigenaar is in complexe organisaties vaak niet werkbaar. De focus van deze eigenaar ligt primair op de business, niet op het dagelijks beheer of de afweging tussen alle belangen.

‍

Een praktische oplossing is het inrichten van een governance-structuur met een board van belangrijke stakeholders. Zij wegen gezamenlijk de belangen en bepalen de prioriteiten. Bij conflicten wordt het besluit voorgelegd aan de systeemeigenaar die uiteindelijk de knoop doorhakt. Zo worden belangen expliciet gemaakt, keuzes onderbouwd en blijft er één duidelijke beslisser.

‍

Herken je dit soort dilemma’s in jouw organisatie? Dan is de vraag niet of eigenaarschap nodig is, maar hoe je het zo organiseert dat het ook daadwerkelijk werkt.