Grip op outsourcing

Nu een groter aantal organisaties haar IT buiten
de deur heeft gezet, blijkt dat niet altijd op
rolletjes te lopen.  En dan bedoel ik niet de
huidige turbulentie bij ING naar aanleiding van
de overgang van 400 medewerkers naar drie
outsourcers, maar wel dat de samenwerking als
zodanig niet gestroomlijnd is.  Zowel de IT
service providers als de klanten moeten zich
aanpassen aan de nieuw ontstane situatie waarin
professioneel demand management en een IT-supply
organisatie wezenlijke onderdelen moeten worden.
Bovendien zitten er vaak omvangrijke contracten
tussen.  Problematische situaties geven soms
aanleiding tot issues waarbij men de kleine
lettertjes van de contracten probeert te
interpreteren.  En die bieden niet altijd evenveel
soelaas, met een onprettige samenwerking tot
gevolg.

Dat komt vooral omdat contractmanagement nog in
de kinderschoenen staat.  Met alle respect voor
de inkopers en juristen zijn het vaak diegenen
die de contracten opstellen en de prijzen
vastleggen.  Een gemiste kans in outsourcing
contracten is bijvoorbeeld de opname van een
setje belangrijke IT-specifieke indicatoren die
de grip op het dagelijkse werk verbeteren, door
monitoring, control, transparantie en meer.  Een
veel gemaakte fout is bijvoorbeeld de
acceptatietest om af te rekenen.  Ik gaf in een
eerdere column aan dat een dergelijke test voor
dat doel niet geschikt is, omdat je daarmee
gemiddeld maar 30% van de fouten in software
opspoort.

Wat moet je nu aan KPIs in een outsourcing
contract opnemen zodat je minimaal grip op de
situatie krijgt zonder al te veel discussie over
de metrieken zelve?  Dat is een verhaal dat van
twee kanten moet komen.  Optimaliseren naar
resultaatgericht werken betekent dat de klant in
staat is een opdracht te formuleren, en de
leverancier in staat gesteld wordt om op te
leveren.

Dus vage plannen die de hele tijd veranderen
dragen daar niet aan bij.  Het is derhalve goed
om de volatiliteit van het eisenpakket binnen de
perken te houden.  Dat doe je door de zogenaamde
scope creep onder de 1% groei per maand te
houden.  Het eisenpakket gemeten in functiepunten
aan het eind van de requirements fase mag bij
oplevering niet meer dan 1% per maand zijn
aangewassen.  Sterker, outsourcing deals met een
maandelijkse groei van meer dan 2% zijn een
indicatie dat er iets mis kan zijn.  Scope creep
boven de 5% is een sterke indicator dat het
project hoogstwaarschijnlijk in de problemen
verkeert.

Voorts is een bepaalde minimale kwaliteit
vereist.  Je kunt niet tegen een minimaal
uurtarief eisen dat er nul fouten in de software
op zullen treden.  Kwalitatief goede IT-ers
hebben hoge uurtarieven, gelukkig ze zijn vaak
vele malen productiever dus dat geld komt wel terug.
Hoeveel fouten mogen er in opgeleverde
software zitten zodat er nog steeds sprake is van
een succesverhaal, en bij welk aantal wordt het
minder fraai?  Minder dan vijf fouten per
functiepunt in het "totale volume" van de
software, en je zit redelijk goed.  Totaal volume
wil zeggen fouten in requirements, in het
ontwerp, in de code, de documentatie, en door
incorrect verbeterde fouten.  Ook dit is een
sterke discriminant: zes of meer fouten per
functiepunt is een signaal, en bij hogere
aantallen is er aanleiding tot grote zorg.
Vergelijk het maar met de oplevering van een
eensgezinswoning waar gemiddeld nog 21 defecten
aanwezig zijn.  Als dat substantieel hoger is, is
dat een indicatie dat het hele huis niet goed
gebouwd is.

En dan de defect removal efficiency (DRE) waar ik
in de vorige column al op inzoemde.  Dat is het
percentage fouten dat je voor oplevering van een
(tussen)product hebt gevonden en verbeterd.  Je
kunt minimaal naar twee van die percentages
kijken.  Om verassingen te voorkomen bij
oplevering, is het aan te raden om bij een
belangrijke mijlpaal alvast een defect removal
efficiency af te dwingen.  De DRE voordat je gaat
testen is er nuttige om contractueel vast te
leggen.  Als die meer dan 65% is, met andere
woorden voordat je gaat testen heeft de
outsourcer er al 65% uit gehaald, dan heb je
hoogstwaarschijnlijk te maken met een project dat
op het juiste spoor zit.  Is het 35% of minder,
dan moeten we eerder aan een ontsporing denken.
Meteen na het testen is dat dan bekend.  En omdat
je dit per contract hebt vastgelegd is er ook
transparantie over de reeds opgeloste problemen,
die de leverancier graag rapporteert omdat dat
tot een hogere DRE bijdraagt.

Het voordeel van dit soort KPIs is dat de
leverancier maatregelen moet nemen om zo vroeg
mogelijk in het traject fouten te vinden en te
voorkomen, wat de kwaliteit alleen maar ten goede
komt en ook nog eens goedkoper is.  Immers, hoe
sneller je een fout ontdekt hoe minder het kost
om hem ongedaan te maken.  Als vierde KPI is het
raadzaam om een defect removal efficiency before
delivery te eisen.  Een DRE van meer dan 94% is
een mooi resultaat, en minder dan 85% is
problematisch.

De combinatie van deze vier indicatoren tegelijk
maakt het verschil tussen falende en succesvolle
projecten.  Uiteraard kunnen en zullen de
precieze cijfers per geval iets anders zijn: al
naar gelang de grootte, complexiteit, en het type
project.  Laat onverlet dat dit soort KPIs
expliciet opnemen in contracten bijdraagt om een
goede relatie tussen IT dienstverleners en hun
klanten te bevorderen.

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.