Afrekenen met outsourcing

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 organizaties 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 levenswandel van vele softwaresystemen 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 procent van de fouten. Na afrekening heb je dan nog 70 procent 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 procent. 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 10.000 regels code) een DRE van 95 procent, bij middelgrote systemen met honderduizenden regels code is dat al gedaald naar 88 procent, en bij de grote systemen met miljoenen regels code zit men gemiddeld op 82 procent. Dus als je gaat outsourcen naar vaklui moet dat beter kunnen. Bij outsourcers zijn de netgenoemde gemiddelden eenstuk beter: respectievelijk 97-, 95-, en 93 procent. 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.

Prof. dr Chris Verhoef is hoogleraar informatica aan de Vrije Universiteit in Amsterdam. Hij schrijft regelmatig een column in AG.