financieel

Bellenblazen met de Resultatenbox DUO

Als je eenmaal ooit Hans Rosling zijn presentatie op TED over Gapminder hebt gezien dan wacht je gewoon tot je voor het eerst zelf data tegenkomt met 2 of 3 ruimte-dimensies en één tijd-dimensie. Hij visualiseert statistieken als volgt:

  • Twee dimensies of ratio’s bepalen de plaats van een ‘bel’ op de assen.
  • Een derde dimensie bepaalt de omvang van de bel.
  • Door deze plaat te maken voor meerdere jaren kan hij de bellen laten ‘bewegen’.

Onlangs publiceerde DUO de indicatoren MBO. Deze cijfers kunnen door instellingen worden gebruikt om op te nemen in hun jaarverslag of “Geïntegreerd Jaardocument”. Definities zijn ook te vinden in de informatie-encyclopedie. DUO laat het je downloaden in excel. Niet helemaal genormaliseerd maar ja, het moet wel leesbaar blijven. [Wie vindt er trouwens de fout in de kop met jaartallen?]

Als je deze data normaliseert en in Google Spreadsheets laadt krijg je het onderstaande resultaat. Als je op de afbeelding klikt, kom je in de ‘echte’ versie:

Gapminder Rentabiliteit en Solvabiliteit MBO

 

Werk als volgt:

  • Druk op de knop “Play” om de ontwikkeling door de jaren heen te volgen.
  • Kies rechtsboven bij “Kleur” voor “Unieke kleuren” om de instellingen visueel te onderscheiden.
  • Vink bij de lijst met instellingen aan welk MBO je wilt volgen. Er wordt dan een ‘pad’ getekend.

Ik ben helemaal geen expert op het gebied van financiële indicatoren, de inspiratie voor deze assen kreeg ik van Onderwijsgrafiek zijn blogpost over de financiele positie MBO. Overigens vindt ik dat een betere plek voor deze cijfers een MBO variant van Vensters voor Verantwoording zou zijn.

 

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?