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?

2 comments

  1. Joël, er is nog een andere mogelijkheid.
    Beschouw de mogelijkheid om gebruik te maken van de applicatie als een dienst die door één van de stafdiensten wordt geleverd aan de afdelingen/scholen/sectoren. Zo zouden onderwijsapplicaties eigendom zijn van een dienst Onderwijs o.i.d. Eigenaar is de directeur van de betrokken stafdienst.
    Sluit voor gebruik een SLA af waarvoor wordt betaald. Organiseer een gebruikersoverleg waarin deelnemers eventueel naar rato zeggenschap hebben over inrichting en doorontwikkeling. Als eigenaar heeft die de verantwoordelijkheid om de belangen van de applicatie (lees: dienstverlening) te behartigen binnen de organisatie. Bij besluitvorming met consequenties voor de applicatie (bijvoorbeeld een vervanging of andere inrichting van een bronapplicatie die gegevens levert aan deze applicatie) dient de eigenaar die in de besluitvorming te betrekken (“jongens, let op: als je dit doet dan heeft dat die en die gevolgen voor …”). Wanneer het besluit er eenmaal is, treedt de eigenaar op als opdrachtgever voor de aanpassingen in de betreffende applicatie.

    Eigenlijk een combinatie van 1, 2 en 3.

    Succes…

  2. Hé, bedankt voor dit construct! Belangen worden behartigt (als de dienstverlening goed verloopt), èn er is zo een financieel construct. Dus de eigenaar hoeft niet persé de lijnmanager te zijn van de groep eindgebruikers. De eigenaar wordt diensverlener en de lijnmanagers, die boven de respectieve eindgebruikersgroepen, staan worden dienstafnemer.
    Eigenlijk generiek als construct te gebruiken, vergt alleen wel communicatie en rijpheid om die construct te doorgronden. Ik denk dat ik eens ga tekenen…
    Bedankt!

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s