Goed besluit over software vergt de juiste argumenten

Professor Chris Verhoef breekt lans voor software asset
management op niveau raad van bestuur

Grote bedrijven gaan vaak slordig om met hun software,
terwijl die toch vaak een strategisch middel is. Directies
moeten leren hun software op waarde te schatten, met
behulp van de juiste argumenten, vindt VU-professor Chris
Verhoef. Je laat het vastgoedbeheer ook niet over aan de
concierge.

Jaren kibbelen over de modernisering van een systeem;
softwareprojecten die al vijf keer opnieuw zijn begonnen;
het is geen uitzondering, ook niet in grote bedrijven.
Het onderhoud, het operationeel beheer, de vernieuwing
en de eventuele vervanging van software betekenen allemaal
dat die software kennelijk iets betekent voor een bedrijf.
Toch krijgt software niet de plaats die zij verdient in
de beslishirarchie van het bedrijf, vindt professor dr.
Chris Verhoef, verbonden aan de faculteit der exacte
wetenschappen van de Vrije Universiteit in Amsterdam.

Mijn ervaring is dat beslissingen over IT vaak niet
structureel geregeld zijn. Vrijwel altijd als ik door
bedrijven benaderd word, liggen mensen al langdurig met
elkaar in de clinch over allerlei onduidelijkheden en
zijn ze appels en peren aan het vergelijken. Men probeert
al vijf keer een systeem te vernieuwen en het lukt maar
niet.

Verhoef, ook verbonden aan het Amerikaanse Software
Engineering Institute (SEI) en wetenschappelijk hoofdadviseur
van de Deutsche Bank, probeert dan helderheid te scheppen.
Het gaat erom dat mensen op dat soort posities met de
juiste argumenten beslissingen nemen over software.

Over het algemeen behoeft software meer aandacht dan zij
nu krijgt, vindt hij, maar met alleen aandacht ben je er
niet. De omgang met software Verhoef gebruikt de term
software asset management  vergt ook het slim gebruiken
van een aantal metingen en indicatoren. Met enige inspanning
leiden die tot argumenten waar je als lid van een raad
van bestuur iets mee kunt. Op het moment dat je je
realiseert dat bepaalde software niet een kostenpost is,
maar een strategische asset, ga je anders nadenken over
die software.

Strategisch

Verhoef onderscheidt vijf aspecten van software asset
management, die in elkaars verlengde liggen. Het strategische
aspect is het belangrijkste. Het gaat erom dat iemand op
het hoogste niveau snapt hoeveel iets kost, waarom het
zoveel kost en hoe dat gebudgetteerd moet worden. Dit
soort zaken gebeurt vaak niet goed, dus je krijgt politieke
spelletjes tussen afdelingen of tussen uitbesteder en
dienstverlener, omdat men de controle kwijtraakt. Als je
een nieuw gebouw koopt of je laat je gebouw ingrijpend
veranderen, dan kun je ook niet zeggen laat dat maar over
aan de concirge.

Een raad van bestuur moet dit soort dingen managen op
strategisch niveau en met een blik op de langere termijn.
Een goede vertrouweling is dan wel nodig. Maar gemiddeld
is een CIO niet langer dan tweenhalf jaar op die positie
en dat klopt niet met het zijn van een vertrouweling van
de raad van bestuur, want die moet ook naar de
langetermijnvisie kijken. De gemiddelde chief information
officer ontworstelt zich volgens Verhoef niet aan de
impressie dat hij verantwoordelijk is voor mislukkingen,
te late oplevering, budgetoverschrijdingen en andere
problemen met softwareprojecten. Het uitleggen van de
complexiteit van softwareontwikkeling smoort in een gebrek
aan vertrouwen. Je ziet zelfs dat het moeilijk wordt
opvolgers te vinden voor de positie CIO.

In het verlengde van die politiek/ strategische kwestie
liggen de financieel-economische vragen: hoeveel kost
software eigenlijk?, wat voor budget heb ik nodig om de
software in de lucht te houden of aan te passen?, hoe
bereken ik dat en hoe zie ik of het iets oplevert?. Dus
wat je vaak ziet is dat men 100 miljoen dollar om een
softwaresysteem te verbeteren wel erg veel geld vindt.
De vraag die gesteld zou moeten worden is wat levert die
software aan business value op en hoe verhoudt zich dat
tot een investering van 100 miljoen dollar?.

Die vraag moet volgens Verhoef niet verward worden met
de gangbare discussie over return on investment (ROI).
Die discussie gaat over de winst, afgezet tegen het
IT-budget. Maar er is door Paul Strassman aangetoond dat
daar eigenlijk geen verband tussen bestaat. Je moet niet
kijken naar hoeveel er wordt besteed, maar naar hoe
effectief.

Stel, je overweegt een groot softwaresysteem op een
mainframe in Java opnieuw te maken. De vraag is of dat
verantwoordbaar is. Je kijkt dan naar de risicos. Ik heb
dat voor een bedrijf wel eens uitgerekend en als ze dat
zouden uitvoeren en je zou de afbreukrisicos erbij nemen,
zou het om 6 of 7 procent van de totale jaaromzet gaan
dat kan dus gewoon niet. Maar zodra je dat soort berekeningen
bij de raad van bestuur voor het voetlicht brengt, zien
ze ogenblikkelijk wat voor besluiten ze moeten nemen.

Verhoef gebruikt soms relatief simpele gegevens, zoals
een schatting van het aantal functiepunten van het te
ontwikkelen systeem en benchmarking-gegevens over de
daarmee samenhangende slagingskans. Vaak is men al jaren
aan het praten, maar de discussies convergeren niet,
omdat men niet aankomt met de juiste berekeningen. Kennis
van benchmarking-data is dus onontbeerlijk, meent hij.
Verhoef kijkt ook vaak naar een metriek die dollar asset
responsibility heet, de hoeveelheid geld die je per
tijdseenheid toevertrouwt aan een systeem.

Zo kan de NS bijvoorbeeld uitrekenen wat bij het uitvallen
van hun dienstregelingensysteem de gevolgen zijn in
gederfde inkomsten uit de kaartjesverkoop en de vergoedingen
die ze sinds kort voor vertragingen uitbetalen. Soms wil
men van een systeem af en dan reken ik uit dat er 200.000
gulden per seconde door gaat. Als een raad van bestuur
zich dat realiseert, is het zeer eenvoudig te beslissen
daar hun middelen op in te zetten. Maar als dat soort
zaken niet bekend is, wordt de software alleen als een
kostenpost gezien.

Deskundigheid

Een volgende aspect betreft het management. Als je alles
hebt doorvertaald naar die raden van bestuur, kun je
besluiten hoe je het gaat managen. Als men doorheeft dat
software een belangrijke asset is, is het niet meer
onmogelijk die te managen, al komt daar nog heel wat
deskundigheid bij kijken.

Vervolgens komt ook het technische personeel in zicht.
Je moet weten he je bepaalde zaken uitvoert. Dat is waar
men meestal naar kijkt als men het over beheer heeft,
maar dat is een veel te gesoleerde view op hoe het in
zon organisatie zit. Dat is in feite hetzelfde als wanneer
je een verhuizing naar een nieuw kantoor overlaat aan
het verhuisbedrijf. Ook juridische aspecten kunnen onder
software asset management gerekend worden:  uitbesteding,
auteursecht et cetera.

Software asset management is  meer een integrale aanpak
dan een functie, valt uit Verhoefs woorden te concluderen.
Een raad van bestuur beheert het onroerend goed, de human
resources, de juridische zaken, de financin, de machines.
Als ze erachter zijn dat bepaalde stukken software
bedrijfskritisch zijn  in eerste instantie weet men dat
vaak niet  moeten ze die dus gewoon ook managen. Software
is zeker geen vrachtwagen, dus er komen wat andere
vaardigheden bij kijken. Maar vergelijk het maar met
human resources; daar zit ook een kenniscomponent in.

Professor Chris Verhoef: Op het moment dat je je realiseert
dat bepaalde software niet een kostenpost is, maar een
strategische asset, ga je anders nadenken over die
software.  foto: anp (fbl)

Weekblad 2001, week 42

Meer weten over de wondere wereld van ICT 
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Deze tekst is copyright SDU.  Niets van deze uitgave
mag zonder schriftelijke toestemming van de uitgever
worden overgenomen of worden gepubliceerd.