Outsourcing zorgt voor betere requirements

outsourcing

t

Outsourcing zorgt voor betere requirements

We moeten wel!

In veel organisaties is sprake van gebrekkige requirements en requirementsprocessen. Outsourcing lijkt dan geen goed idee. Outsourcing biedt echter kansen om het belang van requirementsprocessen te benadrukken. De auteur geeft aan hoe outsourcing als hefboom kan werken voor de verbetering van requirementsprocessen.

Johan Zandhuis

informatie / oktober 2008

Beheerst outsourcen binnen systeemontwikkeling vereist een goede set van requirements bij de start van projecten en goede beheersing van requirements gedurende de projecten. Toch lukt dat lang niet alle organisaties die systeemontwikkeling outsourcen of dit overwegen. Veel interne professionals op de werkvloer, medewerkers met materiedeskundigheid, onderkennen het gevaar en zien het besluit tot outsourcing met lede ogen aan. Ze kennen de huidige werkwijze binnen projecten en voorzien kostenstijgingen in plaats van de door outsourcing beoogde en beloofde kostenbesparingen. Outsourcing biedt echter kansen om requirementsprocessen en het belang ervan nadrukkelijk op de kaart te zetten. En laat dat nu juist ook een van de belangrijkste verbeterpunten zijn die, als je het aan diezelfde professionals vraagt, vaak naar voren komen. Outsourcing kan als hefboom werken voor de verbetering van requirementsprocessen.

44

Outsourcing: worden we er nu beter of slechter van? Bij een groeiend aantal organisaties die tot nu toe intern software ontwikkelen, speelt momenteel de discussie over outsourcing. Bij veel organisaties heeft men net het besluit genomen en begint men aan het avontuur. Maar dikwijls

bekijken medewerkers die werkzaam zijn in het domein van informatieanalyse, systeemontwikkeling of testen, dergelijke ontwikkelingen met huiver. Deze professionals worden in de praktijk geconfronteerd met de onduidelijkheden binnen projecten over wat er nu precies moet worden opgeleverd en aan welke eisen informatiesystemen dienen te voldoen. Een groot deel van hun werk bestaat uit het snel afstemmen, oplossen en gladstrijken van dergelijke onduidelijkheden om op die manier toch nog, wellicht iets later en misschien tegen iets hogere kosten, tot de gewenste systeemoplevering te komen. Een logische gedachte is dat dit gladstrijken alleen maar complexer wordt met het verdelen van de systeemontwikkeltaken over verschillende partijen op (grote) afstand. En niet alleen de afstand maar ook verschillende belangen spelen bij het werken met meerdere partijen een rol. In plaats van een besparing en toename in flexibiliteit, waarover bij motivaties voor outsourcing wordt gerept, verwachten deze professionals dat projecten duurder worden en de systeemoplevering juist verder verstart. Geen onlogische gedachte, die in de praktijk ook wel eens realiteit wordt. Professionals zien outsourcing daarom vaak als een bedreiging en beslist niet alleen omdat het een verandering en mogelijk zelfs een bedreiging

Samenvatting Outsourcing kan een mogelijkheid zijn om een pijnpunt aan te pakken dat veelvuldig door IT-professionals als bron van vele problemen wordt aangewezen: gebrekkige requirements en gebrekkige requirementsprocessen. Outsourcing kan worden aangegrepen als hefboom voor een verbetering van requirements en requirementsprocessen. Requirementsvalidatie kan worden aangegrepen als

van hun werk betekent. Ze vrezen niet voor hun eigen hachje maar oprecht voor de resultaten van de organisatie, hún organisatie. Wanneer ze deze bezwaren uiten, wordt dat soms gezien als weerstand tegen verandering en wellicht een uiting van angst voor behoud van de eigen werkplek. De bezwaren vinden dan bij de mensen die tot outsourcing besluiten weinig tot geen begrip. Maar outsourcing kan ook een mogelijkheid zijn om, los van alle andere motieven om te gaan outsourcen, een pijnpunt aan te pakken dat veelvuldig door diezelfde medewerkers als bron van vele problemen wordt aangewezen: het probleem van gebrekkige requirements en gebrekkige requirementsprocessen (zie kader). Oftewel: met outsourcing uiteindelijk weer meer grip op de zaak. En met die insteek hebben directie, management en werkvloer juist wel een gemeenschappelijk doel.

Outsourcing + gebrekkige require ments = kostenverhoging

1. In dit artikel wordt geen verdere motivatie voor de noodzaak tot regievoering bij outsourcing gegeven. Hiervoor wordt verwezen naar onder andere Gianotten & Wijers (2005) en andere onderzoeken door Giarte.

De weerstand en huiver bij professionals is terecht als er bij outsourcing aan de wijze van opdrachtverstrekking en projectvoering ten opzichte van de oude situatie verder niets verandert. Outsourcing zonder concrete en complete requirements maakt alleen contracten in de vorm van een inspanningsverplichting mogelijk, geen resultaatverplichting. Het gewenste projectresultaat is immers bij gebrekkige requirements vooraf nauwelijks meetbaar vastgelegd. De opdrachtnemer weet in die situatie niet precies wat van hem wordt verwacht en dus niet welke inspanning dat vereist. Net als in de oude situatie bestaat een groot deel van het werk uit het oplossen en gladstrijken van onduidelijkheden, onduidelijkheden die feitelijk als omissies in de requirements te beschouwen zijn. Een complicerende factor is dat bij outsourcing nu ook de vraag ‘wie gaat dit betalen?’ een expliciete rol speelt. Is er bij een vaag omschreven resultaat wel sprake van een concreet afgesproken budget, dan speelt

bij een ervaren leverancier vaak een hoog opslagpercentage voor risico’s een rol. De vele aanpassingen en wijzigingsverzoeken die binnen een dergelijk project gegarandeerd gaan spelen, worden dan door de leverancier welwillend en zonder al te veel morren geaccepteerd. Op het moment dat de grenzen van het budget bereikt worden, zal de leverancier alle verdere vragen en aanpassingen als meerwerk gaan beschouwen. Dat kan een leverancier dan ook zonder veel discussie doen, gezien de vele wijzigingen die eerder al zonder berekening van meerwerk zijn geaccepteerd. Een andere in de praktijk voorkomende werkwijze is dat de leverancier op enig moment in het project een specificatiedocument opstelt, bijvoorbeeld een functioneel ontwerp. Dit document wordt vervolgens tot uitgangspunt bestempeld. Alle aanvullende eisen, die niet specifiek uit dit door de leverancier opgestelde document blijken, worden dan als meerwerk beschouwd. Zo kan een leverancier uiteindelijk toch nog winstgevend werken. In feite doen dan in het geval van outsourcing ten opzichte van de situatie van interne systeemontwikkeling alleen andere partijen hetzelfde werk en gebeurt dit indirect nog steeds volledig voor rekening en risico van de opdrachtgever. Er is weinig sprake van verandering in de werkwijze, terwijl outsourcing juist een goede gelegenheid kan zijn om processen opnieuw in te richten. Het enige verschil wordt dan gevormd door een extra kostenpost veroorzaakt door de benodigde marge van de toeleverancier. Maar een dergelijke kostenstijging kan nooit de bedoeling van outsourcing zijn en leidt op langere termijn alleen tot verliezers, zowel aan de leverancierskant als aan de opdrachtgeverskant. Er moet dus iets veranderen in de wijze van opdrachtverstrekking en de wijze waarop vervolgens de opdrachtrealisatie namens de opdrachtgever wordt bewaakt. Deze vorm van opdrachtbeheersing bij outsourcing wordt ook wel regievoering genoemd1 (Agterbosch & Cannegieter, 2007).


hefboom om outsourcing beter onder controle te krijgen.

45

outsourcing

t Requirementsoorten en requirementsprocessen Requirements kunnen worden onderverdeeld in een aantal soorten, waarbij ieder niveau van requirements bedoeld is voor een groep belanghebbenden. We onderscheiden de volgende niveaus: • Business requirements: de doelstellingen van de business. Deze requirements bepalen de scope en de richting van de overige requirements. De business requirements geven antwoord op de waarom-vraag van het systeem: waarom moet dit systeem gemaakt worden? • Gebruikersrequirements: de doelen en taken die de eindgebruikers van het systeem moeten kunnen uitvoeren. De gebruikersrequirements geven antwoord op de wat-vraag van het systeem: wat moet het systeem doen? • Systeemrequirements: de eisen of beperkingen waaraan het systeem dient te voldoen om de business- en gebruikersrequirements te realiseren. De systeemrequirements geven antwoord op de hoe-vraag van het systeem: hoe moet het systeem werken om aan de bovenliggende requirements te voldoen? Op elk niveau is nog onderscheid te maken in functionele en niet-functionele requirements. De functionele requirements hebben betrekking op de functies die het systeem voor de belanghebbenden moet vervullen. De niet-functionele requirements zijn eigenschappen of karakteristieken waar het systeem aan moet voldoen. Voorbeelden hiervan zijn beveiligbaarheid en performance. Daarnaast is er een aantal requirementsprocessen te onderscheiden. De verschillende processen zijn weergegeven in figuur 1. Met name requirementsvalidatie speelt een rol in het zichtbaar maken van de kwaliteit van de requirements. Validatie omvat controle van de requirements vanuit een aantal gezichtspunten: • Juistheid: is dit echt wat de opdrachtgever nodig heeft? • Volledigheid: dekt het de complete gebruikersbehoefte af? • Consistentie: de totale set requirementsdocumenten bevat onderling geen tegenstrijdigheden. • Mate van voldoen aan bedrijfs- en industriestandaarden. • Mate waarin de afzonderlijke requirements voldoen aan eisen als: testbaar, identificeerbaar, traceerbaar, vrij van implementatiedetails. Bron: Arendsen e.a. (2008), Succes met de requirements!


requirementsproces

46

requirementsontwikkeling

elicitatie

analyse

requirementsvalidatie

specificatie

Figuur 1. Requirementsprocessen

intake & identificatie

requirementsmanagement

traceerbaarheid

wijzigingsbeheer

verificatie

Vanwege de duidelijke splitsing van verantwoordelijkheden en kosten ten gevolge van outsourcing komt de mogelijkheid tot het ‘direct met elkaar oplossen onderweg’ zoals ten tijde van interne systeemontwikkeling vaak plaatsvindt, te vervallen. Uit onderzoek blijkt dat dit onderweg oplossen van onduidelijkheden geen efficiënte werkwijze is. De wet van Boehm (Boehm, 1981) toont aan dat de herstelkosten tijdens de fase van het opstellen van requirements vele malen lager zijn dan wanneer diezelfde fout pas wordt hersteld tijdens ontwerp, bouw of test. Veel organisaties zijn hier ook al mee bekend. Maar de druk binnen projecten om toch vooral door te gaan naar een volgende fase is groot, vele malen groter dan de druk om de herstelkosten tot een minimum te beperken. Wanneer aan die druk wordt toegegeven, komt het principe van ‘in één keer goed’ en van het volledig en correct afronden van de requirementsfase, inclusief requirementsvalidatie, te vervallen. De activiteiten om de fouten te herstellen zijn interne kosten en zijn niet expliciet zichtbaar. Binnen verschillende organisaties met interne systeemontwikkel- en testafdelingen zijn de opbrengsten van het reviewen van requirements en andere belangrijke mijlpaalproducten zichtbaar gemaakt (Cannegieter, 2007). Over het algemeen resulteert dit in een return on investment van 5 tot 7. Anders gezegd: gemiddeld levert ieder uur geïnvesteerd in reviews een besparing op van 5 tot 7 uur. Goed uitgevoerde requirementsvalidatie toont dit ook aan. Feit blijft dat de kosten (en opbrengsten) vooral interne uren betreffen; ze zijn in de administratie of kostenoverzichten niet in de vorm van facturen terug te vinden. De opbrengsten zijn daardoor minder aantoonbaar en gaandeweg kan de werkwijze om 70 toch vooral door te gaan weer de overhand krijgen, ten koste van het 60 in ‘één keer goed’-principe. relatieve 50 Externe partijen hanteren doorherstelkosten gaans een stringenter wijzigings [%] 40 proces. Wijzigingen in de requirements en de daaruit voortvloeiende 30 kosten zijn in de begroting (change 20 budget) en op de factuur van de leverancier meestal keurig terug te 10 vinden. Dit maakt een veel eenvoudiger analyse mogelijk van welke 0 kosten door een intensievere requirementsfase te voorkomen zijn.

Door outsourcing worden hoge verborgen interne herstelkosten vanuit het verleden ingeruild voor nog hogere externe en dus zichtbare herstelkosten. Waar eerst bij interne systeemontwikkeling alle herstelkosten interne kosten zijn, bestaat bij outsourcing een deel van de herstelkosten uit externe kosten. De figuren 2 en 3 laten zien hoe door outsourcing de kostenstructuur van herstelwerkzaamheden verandert. Degene die de regie voert, heeft inzicht in de wijze van opdrachtverstrekking, alle wijzigingen en de uiteindelijke extra kosten die deze wijzigingen tot gevolg hebben. Regievoerders hebben daarmee alle benodigde gegevens tot hun beschikking. Het structureel inplannen en uitvoeren van een heldere analyse op deze kosten aan het eind van het project, maakt de meerprijs van gebrekkige requirements zichtbaar. Met de resultaten uit deze analyse is een solide businesscase van het verbetertraject voor requirementsprocessen geleverd; de onderliggende facturen zijn er en de kosten zijn daarmee keihard. Een andere insteek is het inzichtelijk maken van de risico’s van outsourcing per applicatie. Dit kan door middel van een checklist. Onderdeel van deze checklist is de mate te bepalen waarin de applicatie onmisbaar is voor het primaire proces. Dit bepaalt het risico dat de organisatie loopt als systeemontwikkeling niet tot het uiteindelijk gewenste resultaat leidt. Verder wordt er met andere vragen gekeken naar de mate van beschikbaarheid van functionele documentatie, de kwaliteit ervan en de mate van overdraagbaarheid van materiekennis. Voor het bepalen van de kwaliteit van de functionele documentatie dienen gedefinieerde en gevalideerde requirements als UPUBMFIFSTUFMLPTUFO FYUFSOFLPTUFOCJKPOUXJLLFMUFTUPVUTPVSDJOH FYUFSOFLPTUFOCJKUFTUPVUTPVSDJOH

requirements

ontwerp

bouw

systeemtest

acceptatietest

productie

fase systeemontwikkeling

Figuur 2. Aandeel externe kosten in de herstelkosten


Waar zit de winst?

47


basis. Zolang er geen gevalideerde set van requirements is, kan de kwaliteit van de functionele documentatie niet worden beoordeeld. De score op deze vragen wordt daarom vooral bepaald door de beschikbaarheid van een eenduidige set van gevalideerde requirements. Zolang de score op deze vragen laag is, kan outsourcing van die applicatie alleen plaatsvinden met extra risicobeperkende maatregelen. Een van die maatregelen is het alsnog vaststellen van een gevalideerde set van requirements. Ten slotte kijkt de checklist nog naar de wijze waarop verder met requirements wordt omgegaan zodra de systeemontwikkeling start, oftewel requirementsmanagement. Hierbij wordt gekeken naar het bestaan van projectprocessen voor overdracht en decharge op basis van requirements. Daarmee komen ook de requirementsprocessen bij de leverancier in beeld.

48

De bovenstaande acties leiden tot het inzicht dat het verbeteren van de requirementsontwikkeling en requirementsvalidatie uiteindelijk veel facturen spaart en risico’s beperkt. Daarmee dwingt outsourcing ertoe om de bestaande inefficiënte werkwijze te vervangen door een zakelijke, efficiëntere en meer beheerste werkwijze. De opdrachtgever stelt duidelijke requirements op die richting geven aan de ontwikkeling van het te leveren eindresultaat. De leverancier stelt daarbij randvoorwaarden aan de opdrachtverstrekking. Het kunnen beschikken over duidelijke requirements is hier een onderdeel van. Door middel van een eenduidige wijze van regievoering op deze processen en kwaliteitseisen ontstaat er ook een basis voor continue verbetering. De verschillende financiële belangen zorgen ervoor dat opdrachtgever en opdrachtnemer elkaar hierin scherp houden en opvoeden. En dat leidt uiteindelijk tot minder verspillingen en meer grip op de zaak!

Ervaringen tot nu toe Bij organisaties waar men is overgegaan op outsourcing, is inmiddels ervaring opgedaan met de noodzaak tot verbetering van opdrachtverstrek-

100 80 60

FYUFSOF IFSTUFMLPTUFO

relatieve kosten [%]

JOUFSOF IFSTUFMLPTUFO

outsourcing

t

120

40 20 0 interne systeemontwikkeling systeemontwikkeling bij outsourcing PPSTQSPOLFMJKLHFTDIBUUFLPTUFO IFSTUFMLPTUFO

Figuur 3. Slechte requirements: stijging totale kosten door hogere herstelkosten king en daarbij behorende duidelijke requirements. De ervaringen tonen inderdaad aan dat als gevolg van onduidelijke requirements bij de start er gedurende het project vermijdbare herstelkosten ontstaan. Met het verbeteren van de regiefunctie binnen een organisatie bestaat ook de mogelijkheid hier meer inzicht in te krijgen. Bij een specifieke organisatie is op basis van het flexibiliteitsargument (te weinig interne capaciteit) besloten tot outsourcing in twee fasen. In eerste instantie werd alleen het testen uitbesteed, de systeemontwikkeling zelf gebeurde nog intern. Dit betekende dat met name regievoering op het testen noodzakelijk was. Voor adequate regievoering is echter wel inzicht in de gehele projectopdracht noodzakelijk: wat zijn de requirements? Aangezien testen slechts een beperkt onderdeel is van de totale systeemontwikkeling, zijn de meerkosten als gevolg van vermijdbare wijzigingen ook beperkt. Of zoals de regievoerder zelf zei: ‘De rekeningen waren nog niet hoog genoeg.’ De betreffende regievoerder kreeg tot dan toe weinig gehoor voor de besparingsmogelijkheden. Inmiddels is bij de betreffende organisatie de outsourcing verder uitgebreid, ook de systeemontwikkeling wordt voor een aantal applicaties uitbesteed. En inmiddels begint de pijn ten gevolge van gebrekkige requirements beter zichtbaar te worden: de changerekening loopt nu (te) snel op. Wat we leren uit deze case is dat het principe klopt dat externe herstelkosten in de vorm van facturen zwaarder wegen dan interne herstelkosten. Wat we er ook uit kunnen leren is dat de externe herstelkosten wel een substantieel onderdeel van de projectkosten moeten zijn, wil men deze herstelkosten serieus nemen.

Bij een andere organisatie is met name vanuit risicomanagement op beheerste outsourcing gestuurd. Daarbij werd de eerdergenoemde checklist gehanteerd. In eerste instantie bleek bijna geen enkele applicatie van enige omvang op basis van de checklist geschikt voor outsourcing, vanwege het gebrek aan duidelijke requirements behorende bij die applicatie. De enige manier om toch aan de outsourcingsdoelstellingen te voldoen was om extra tijd en moeite te steken in het alsnog opstellen van requirements en de validatie ervan. De beschikbaarheid van de requirements en het relatieve gemak waarmee vervolgens ontwerpers, ontwikkelaars en testers hun werk konden doen, bleken dermate leerzaam dat de bereidheid om energie te steken in requirementsontwikkeling, requirementsvalidatie en requirementsmanagement inmiddels aanzienlijk is toegenomen. Naast de toegenomen kwaliteitsbewustwording kan het hanteren van de checklist ervoor zorgen het opstellen, valideren en beheren van requirements binnen deze organisatie op enig moment ‘business as usual’ wordt. Borging hiervan door stringente controle vanuit de afdeling risicomanagement voorkomt dat onder tijdsdruk het toepassen van de checklist weer wegzakt. De beschreven praktijksituaties zijn geen wetenschappelijke studies met hard onderbouwd cijfermateriaal. Ze bevestigen echter wel het beeld dat outsourcing uiteindelijk ook leidt tot bewustwording en inrichting van requirementsprocessen.

cing kan echter ook de bewustwording en de noodzaak tot volwassen requirementsprocessen enorm versterken. De outsourcingsmedaille kent in die situatie dus twee kanten. Interne professionals beschikken door schade en schande wijs geworden over opgebouwde expertise. Door deze expertise te combineren met het inzichtelijk maken van outsourcingsrisico’s en de kostentoename per specifieke applicatie, kan aan de business de noodzaak voor verbetering van requirementsprocessen worden aangetoond. Alleen mensen met voldoende actuele kennis van de systemen zijn hiertoe in staat. Dit betekent dat voor interne professionals met diepgaande systeem- en materiekennis er in het geval van outsourcing veel werk aan de winkel is. De aard van het werk zal veranderen en met zekerheid dwingen tot een grotere mate van pro-

»Outsourcing leidt uiteindelijk tot bewustwording en inrichting van requirementsprocessen

Interne opdrachtgevers zijn zich in een situatie zonder outsourcing vaak onvoldoende bewust van de verantwoordelijkheid voor en betrokkenheid bij het opstellen en valideren van requirements. Repareren onderweg is dan de regel. De kosten die het gevolg zijn van deze handelswijze, zijn niet zichtbaar. Daardoor is er geen bewuste noodzaak tot het verbeteren van de wijze van opdrachtverstrekking, met duidelijke requirements bij de start. Tevens wordt wijziging van requirements tijdens het ontwikkeltraject niet als een echt probleem gezien; wijzigingen vinden dan doorgaans ongestructureerd plaats. Outsourcing kan in een dergelijke situatie leiden tot kostenstijging en kwaliteitsreductie. Outsour-

fessionaliteit, gestructureerder werken en minder herstelwerk onderweg – je moet wel! Grijp outsourcing aan als hefboom voor een belangrijke verbetering in plaats van het besluit tot outsourcing te bestrijden, zeker als het besluit al min of meer is genomen. Grijp requirementsvalidatie aan als hefboom om outsourcing beter onder controle te krijgen. Literatuur Agterbosch, O. & H.J.J. Cannegieter (2007). Trend: Regiebureau. Informatie 49/4. Arendsen, M. e.a.(2008). Succes met de requirements! Academic Service. Boehm, B.W. (1981). Software Engineering Economics. Prentice-Hall. Cannegieter, H.J.J. (2007). QA en testen. In: H. van Loenhoud (red.), Software Testen in Nederland. Academic Service. Gianotten, M. & G. Wijers (2005). Regie bij Outsourcing, Aansturing van IT-uitbesteding in de praktijk. Giarte. Putnam, L.H.H. & W. Myers (1996). Executive Briefing: Controlling Software Development. Johan Zandhuis is productmanager bij SYSQA BV, een onafhankelijke organisatie gespecialiseerd in quality assurance, testen en prestatieverbetering van IT-organisaties. E-mail: jzandhuis@ sysqa.nl.


De outsourcingsmedaille kent twee kanten

«

49

Outsourcing zorgt voor betere requirements

Recommend Documents