Afrekenen met outsourcing

Wanneer is software af?  Die vraag had je vroeger
wel in de zin van deadlines, maar als men bij
oplevering fouten ontdekte, dan waren dat
kinderziektes, en als we die overleefden, werd
het even rustig.  Daarna leerde de gebruiker de
(on)mogelijkheden van de systemen kennen gevolgd
door updates, change requests, verbeteringen.
Langzaam maar zeker werd de software volwassen,
en kwam tot volle wasdom.

Maar de tijd verstrijkt, en met de ouderdom komen
de gebreken: van kinderziektes via groei en een
volwassen bestaan, duiken er geriatrische
klachten op.  Wat vroeger gemakkelijk ging, is nu
niet meer te doen, de kleinste wijziging vergt
een bovenmenselijke inspanning.  De weg naar
palleatieve zorg wordt dan door sommige
organisaties ingeslagen: via herstructurering,
opknippen, dode code verwijderen, obsolete
constructies omzetten, redundantie verwijderen,
klonen consolideren, en meer techniek lukt het om
de uiterste houdbaarheidsdatum van de software
fix naar achteren te dringen en het
aanpassingsvermogen is weer op peil.

Op de keper beschouwd zou je uit de historie van
de levenswandel van vele software systemen kunnen
concluderen dat software nooit af is en hoe ziek
ook, vrijwel nooit het loodje legt.  Of zoals een
CIO van de Amerikaanse defensie het eens
formuleerde: software is a new form of
immortality.  Tegelijkertijd is de huidige
situatie ook verre van ideaal.  Zeker als je in
de situatie zit waar de green screens de
boventoon voeren terwijl je zelf op je mobieltje
het web kunt raadplegen, heb je al snel het
gevoel dat er iets grondig anders moet.  En
iedereen die dat te enthousiast in de praktijk
brengt leert vroeg of laat dat juist die software
onuitroeibaar blijkt.

Bijvoorbeeld door de hele bubs over de schutting
te gooien:  outsourcen die handel.  De levensloop
van software veranderd natuurlijk niet.  Nog
steeds ga je de weg die anderen gegaan zijn.
Maar ja, kinderziektes of niet, updates of niet,
stroeve systemen of niet, eens moet er afgerekend
worden voor geleverde diensten.  In contracten
zie je dan ook afrekenmomenten en de condities
waaronder.  Een natuurlijk moment is uiteraard de
oplevering van een nieuw systeem.  Een conditie
die ik veel zie is de acceptatietest, en als die
goed uitvalt kan de rekening de deur uit.

Dat klinkt plausibel, maar deze garantie kan ik
je nu al geven: nooit accepteren op basis van een
gebruikerstest, een productieaccepttietest, of
andere eindtest.  De reden is heel simpel: bij
dat soort tests vind je volgens
benchmark-onderzoek gemiddeld 30% van de fouten.
Na afrekening heb je dan nog 70% latente
problemen onder de motorkap.  Als die zich
redelijk snel openbaren kun je vast nog wel iets
regelen, maar hoe sterk sta je als je na 9
maanden een groot probleem ontdekt?

Een manier om dit soort zaken te regelen, is om
per contract een defect removal efficiency (DRE),
af te spreken.  De DRE is het percentage fouten
dat is gevonden en verwijderd voor oplevering.
Dus stel dat er 100 fouten in een stuk software
zitten, en voor oplevering heeft men er al 90
gevonden, dan is de DRE 90%.  Je kunt nu
afspreken wat de DRE moet zijn na oplevering.
Dat betekent dat de software engineers belang
hebben bij het melden van elke fout plus
oplossing, want hoe meer fouten verwijderd
worden, hoe groter de kans dat de DRE gehaald
wordt.  Dus het levert je transparantie op.  En
verder spreek je een tijd af, zeg een jaar
gebruik waarin elke fout die gevonden wordt de
DRE bepaald.  Als je dan na 9 maanden een
probleem aantreft, is het tevens het probleem van
de outsourcer.

Wat is nu een goede DRE?  Gemiddeld zie je bij
kleine in-house ontwikkelde informatiesystemen
(zeg 10000 regels code) een DRE van 95%, bij
middelgrote systemen met honderduizenden regels
code is dat al gedaald naar 88%, en bij de grote
systemen met miljoenen regels code zit men
gemiddeld op 82%.  Dus als je gaat outsourcen
naar vaklui moet dat beter kunnen.  Bij
outsourcers zijn de netgenoemde gemiddelden
een stuk beter: 97%, 95%, en 93%,
respectievelijk.  En gegeven de omvang moet een
systeem minstens scoren op de DRE, en als je
best-in-class nodig hebt, dan zijn de cijfers 99,
99, en 96 procent.

Dit is een manier om kwaliteitsborging in
outsourcing-deals per contract te regelen.  En
het stimuleert transparantie over het verloop van
de bouw.  Al naar gelang het halen van de DRE,
wordt ook de eindafrekening bepaald.  Ook een
bonus/malus systeem behoort dan tot de
mogelijkheden.

X

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

Prof. dr Chris Verhoef is hoogleraar informatica 
aan de Vrije Universiteit in Amsterdam.  Hij
schrijft regelmatig een column in AG II.  Hij is
te bereiken via email:  x@cs.vu.nl.  Deze tekst is 
copyright SDU.  Niets van deze uitgave mag zonder
schriftelijke toestemming van de uitgever worden
overgenomen of worden gepubliceerd.