Tag Archives: eigenaarschap

Eigenaarschap van software

We zitten met een probleem. En ik kom er niet heel snel uit. Even eerst een schets van ‘vroeger’ toen alles nog overzichtelijk was:

Een willekeurige afdeling van een instelling maakte, ter ondersteuning van zijn eigen proces, gebruik van een applicatie. Eindgebruikers kwamen bijna allemaal uit dezelfde afdeling of organieke eenheid. De manager hiervan trad op als ‘eigenaar’. Zodat de faktuur voor licentie, support en/of hosting bij deze persoon terecht kwam. Ook op de begroting hoorde applicatie X dan bij afdeling Y. Als er wijzigingen kwamen, die projectmatig geïmplementeerd werden, dan kwam de projectleider uit diezelfde afdeling. Functioneel beheer en applicatiebeheer kon ook ongestoord door elkaar lopen.

Maar wat gebeurd er als een applicatie processen ondersteunt uit meerdere afdelingen, die ‘in de lijn’ vallen onder verschillende managers? Dit speelt bij ons heel erg als applicaties ‘groeien’, soms vanwege ‘feature-creep‘, soms omdat een suite meerdere modules gaat bieden, soms omdat zaken gaan integreren (portalisering aan de voorkant).  Enkele organisatorische  mogelijkheden, met soms financiële gevolgen:

  • Wijs 1 eigenaar aan: Uiteindelijk is er altijd één eigenaar aan te wijzen, als je maar lang genoeg omhoog gaat in het organogram. Maar het is een beetje flauw om dan altijd ‘de instelling’ (College van Bestuur, Topmanagement etc.) eigenaar te maken van alles. Voordeel: voorkomt discussie bovenin de organisatie. Nadeel: veroorzaakt discussie onderin de organisatie. Omdat onderin niet duidelijk is wie ‘de baas is over de applicatie’.
    Financieel: de applicatie kan gefactureerd en begroot worden op instellingsniveau.
  • Maak een ‘Vereniging  van Eigenaren’. Waarin de belangen worden behartigd van verschillende groepen eindgebruikers. Nadeel: het vergt van ‘stake-holders’ rijpheid om in een VVE niet alleen politiek op te treden, maar ook  functioneel. Voordeel: er is dan een gremium dat iets lager in de organisatie ligt, en waarin functionaliteitsbehoeften integraal afgestemd kunnen worden.
    Financieel: de applicatie kan gefactureerd en begroot worden op instellingsniveau. Maar er zou een doorbelasting kunnen plaatsvinden naar rato van gebruik in de organisatie. Hier zijn allerlei wegingsfactoren te bedenken. Zoals aantallen eindgebruikers. Iets moeilijker: hoe zou je hoeveelheid gebruikte functionaliteit naar rato door kunnen belasten?
  • Maak de lijnmanager van de afdeling die ‘grootverbruiker’ is eigenaar. Veel software kent wel accenten en worden meer door de ene dan de andere afdeling gebruikt. Voordeel: voor de werkvloer heel erg duidelijk. Nadeel: er moet Functioneel Beheer uitgevoerd worden voor andere afdelingen dan de eigen. Daar heb ik minder goede ervaringen mee.
    Financieel: de applicatie kan gefactureerd en begroot worden op niveau van de afdeling. Andere afdelingen voelen financieel niets, maar verliezen dan ook een mechanisme om (kostbare) wijzigingen die alleen voor hun nuttig zijn door te voeren.

De laatste ben ik sowieso niet voor. Maar ik sta wel open voor suggestie! Dus: zijn er meer mogelijkheden?