Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Vijf observaties

Problemen en misverstanden rondom IT-offshoring

Bang

Onlangs is een interessante discussie gestart op het Computable-forum naar aanleiding van het beantwoorden van een aantal Tweede Kamervragen door minister Verhagen, over het vertrek van kennisintensieve R&D activiteiten uit Nederland naar lagelonenlanden. De discussie die zich ontspon richtte zich vooral op het onderwerp it-offshoring. De vaak emotionele uitspraken in de reacties illustreren dat het hier om een onderwerp gaat waarover de meningen en ervaringen sterk uiteenlopen en die veel mensen aan het hart ligt. Vooral de discussie rond kostenbesparing en kwaliteit is een steeds terugkerend thema wanneer we het over it-offshoring hebben.

Vanuit de TU-Delft leid ik het onderzoek en onderwijs rond gedistribueerde software ontwikkeling. Verzamelen van best-practices en bad-practices rond offshoring is hierin een integraal onderwerp. Ik wil dan ook van de gelegenheid gebruik maken om enige nuance toe te voegen over dit onderwerp. Dat probeer ik te doen door vijf observaties te beschrijven die we waarnemen in de praktijk en die een bron zijn voor veel problemen en misverstanden.

Observatie 1: Vaak wordt vergeten dat it-offshoring een wederzijds leertraject is

Het succesvol inzetten van it-offshoring is een traject waarin de verschillende partijen van en met elkaar leren samenwerken. Het is een utopie dat offshoring een kwestie is van: een contract afsluiten en even snel wat taken overdragen waarna op exact dezelfde manier met exact dezelfde prestaties verder kan worden gewerkt. Ons vak kan alleen succesvol worden uitgevoerd met goed geoliede werkprocessen, transparantie, technische vaardigheden en domeinkennis. Het kost tijd voordat deze worden opgebouwd en dit kost dus ook tijd als we offshoren. Zowel aan de vragende kant (opdrachtgeverschap) en leverende kant is het zaak om te leren samenwerken. Dat is altijd al zo dus zeker ook wanneer er wordt samengewerkt over duizenden kilometers heen. De praktijk laat zien dat het al gauw een half jaar tot zelfs enkele jaren kan duren voordat een offshore team op dezelfde prestaties zit als een onshore team. Hoe meer nadruk er wordt gelegd op het leerproces in de samenwerking, hoe sneller dit gaat. Agile methoden die focussen op communicatie, samenwerking en korte iteraties bieden in dergelijke situaties grote voordelen en kunnen dit versnellen tot enkele maanden.

Observatie 2: Complexiteit van het it-vak wordt vaak onderschat door management

De beslissing om te gaan uitbesteden en/of offshoren is een strategische keuze waarin de voordelen en nadelen evenwichtig meegenomen dienen te worden. Puur en alleen naar het aantal medewerkers kijken en uurtarieven vergelijken is een schadelijke versimpeling van ons vak, en indien gebruikt voor onderbouwing van de business-case voor offshoring leidt dit tot teleurstellingen. Sommig werk leent zich goed voor offshoring, ander werk minder. Sommige taken zijn strategisch, andere minder. Sommige bedrijfsprocessen lenen zich voor uitbestedingen en andere weer niet. Zodra de afweging om te gaan offshoren op algemene hoofdlijnen wordt genomen zonder rekening te houden met de strategische implicaties en zonder de transitie goed te begeleiden, leidt dit tot teleurstellingen. Het is echter niet terecht om offshoring daar op aan te kijken. Elk goed idee kan immers op een verkeerde manier worden ingezet ten nadele van onszelf.

Observatie 3: Focus op kosten is fundamenteel onjuist

Focus op kosten is vaak een belangrijk aandachtspunt binnen offshoring. Ten onrechte. Ten eerste omdat it-besteding investeringen zijn. Bij investeringen dient te allen tijde de focus op de opbrengsten te liggen en niet op de kosten. Waarborgen van de opbrengsten is belangrijker dan het terugdringen van kosten. In veel offshoretrajecten ligt geen focus op het waarborgen van opbrengsten, waardoor deze dan ook vaak tegen zullen vallen. De belangrijkste voordelen van offshoring liggen in het makkelijker opschalen, toegang krijgen tot schaarse kennis en resources, het benutten van tijdverschillen, en het dichter bij (potentiële) klanten zitten. Dat offshoring ook tot kostenverlaging kan leiden is juist, echter, als het de enige reden is dan valt het toch vaak tegen. Immers, de bijkomende kosten worden vaak onderschat en de tijd die nodig is om te leren samenwerken vraag in eerste instantie om geduld en investeringen. Het toepassen van Agile methoden kunnen ook hier sterk helpen bij de transitie naar offshoring omdat deze het meetbaar leveren van toegevoegde waarde en optimaliseren van return-on-investment centraal stellen.

Observatie 4: Lage kwaliteit is een gevolg en geen oorzaak

Opdrachtgeverschap is een vak. Het aansturen van offshoring is daar onderdeel van. Negatieve ervaringen met offshoring in de vorm van lage kwaliteit zijn symptomen van een niet effectieve samenwerking. Slechte output is een indicatie van: of slechte input of een slecht proces. Met andere woorden: lage kwaliteit vraagt om actie. Het is namelijk een symptoom van een niet effectieve situatie. Lage kwaliteit is geen oorzaak, noch leidt offshoring tot lage kwaliteit. Wel is het natuurlijk zo dat wanneer je niets regelt de kans groot is dat dit leidt tot teleurstellingen, onder meer rond de kwaliteit. De oorzaak daarvan ligt niet in offshoring maar in de manier waarop het wordt uitgevoerd. Er zijn genoeg best-practices aanwezig over hoe succesvolle offshoring kan worden ingericht. De praktijk laat echter zien dat deze vaak niet worden toegepast. Met alle gevolgen van dien. Ook op dit vlak bieden Agile methoden uitkomst doordat ze focussen op frequente feedback, gereed product en op een communicatie-intensieve samenwerking.

Observatie 5: Denken in bedreigingen verblindt het zoeken naar kansen

Een algemene observatie is dat elke verschuiving van arbeid in de geschiedenis leidt tot discussies rond bedreigingen en kansen. De geschiedenis laat tevens zien dat wanneer arbeid zich verplaatst naar andere werelddelen hiervoor andere arbeid terugkomt. Vaak van een hoogwaardiger kennisniveau dan daarvoor overigens. Ook voor it-offshoring is dat het geval. Tegelijkertijd zal nooit al het werk verdwijnen. Immers, als het mogelijk is, is niets effectiever dan een klein multidisciplinair team dat zo dicht mogelijk op het bedrijfsproces zit waar de it wordt ontwikkeld. Beslissingen tot offshoring zijn daarom alleen legitiem als een dergelijke setting niet haalbaar is; meestal in verband met onvoldoende mensen, kennis of ervaring. De grote uitdaging voor de toekomst is om zo snel en effectief mogelijk in te spelen op it-vragen die bedrijfsprocessen helpen om waarde te creëren. Het vergroten van slagkracht en flexibiliteit is daarin cruciaal. Offshoring kan helpen om de slagkracht van onze mensen in Nederland te vergroten. Uiteindelijk gaat het er om dat we waarde creëren. Hoe meer waarde hoe beter. Het denken in ‘kansen' is daarin cruciaal.

Kortom, de discussie rond het nut en de uitdagingen van it-offshoring zal nog wel even voortduren. Met de tijd komen er steeds meer best-practices naar boven, maar tegelijkertijd zien we ook dat veel organisaties deze niet toepassen en hierdoor onnodig leergeld betalen. Echter, de kansen van offshoring moeten niet onderschat worden. Immers, grote schaalvoordelen en toegang tot kennis worden ontsloten. Door verdergaande technologische ontwikkeling worden gevoelsmatige afstanden kleiner en krijgen we in ons vak steeds beter door hoe we offshoring succesvol kunnen inzetten. Het toepassen van de beschikbare best-practices is daarbij noodzakelijk maar deze worden helaas vaak vergeten, met negatieve effecten als gevolg. Het is echter niet terecht om offshoring ‘an sich' daarvan de schuld te geven. Oplossingen en best-practices zijn namelijk wel voorhanden.

Rini van Solingen

Prof.dr.ir. Rini van Solingen is deeltijdhoogleraar Global Software Engineering aan de TU-Delft. Daarnaast is hij als cto verbonden aan iSense Prowareness uit Gouda.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Het belangrijkste voordeel voor de meeste klanten is de vermeende kostenbesparing. Dat deze niet haalbaar is, heeft veel meer te maken dat de tarieven in India helemaal niet meer zo laag zijn als 10 jaar geleden.
Het stukje inefficientie heeft niets te maken met opdrachtgeverschap, maar is veel meer cultuur bepaald. De grote hierarchie in een Indisch bedrijf is een van de oorzaken.

Als ik kijk naar de vijf observaties van Rini van Solingen dan wordt geen enkele observatie in de praktijk goed uitgevoerd. Offshoring wordt nog altijd gezien als een middel om kosten te besparen, waarbij kennis die er in Nederland is wordt uitbesteedt. Zelfs als een klein multidisciplinair team samengesteld kan worden is offshoring voor het management vaak de oplossing om "dure" werknemers te vervangen.
Ik kan me in alle observaties vinden, maar er is één vraag onbeantwoord gebleven. Hoe verkopen we dit verhaal aan een management wat alleen op kosten managed?

Ik heb een IT bedrijf in Duitsland en ik betaal me scheel aan belastingen en andere verplichtingen. Ik krijg aanbiedingen van Duitse firma's die offshoring diensten aanbieden voor 6 USD per uur. Dit is volgens mij geen uitdaging, doch gewoonweg economische diefstal in oneerlijke concurrentie. Als ik goederen koop in China en deze zijn fors onder de prijs en zouden verstorend werken in de markt, dan moet daar een flinke toeslag bovenop worden betaald.
Met diensten zoals deze in offshoring worden aangeboden, mis ik deze component volledig. Ik vind dat diensten van buiten de EU aangeboden, minstens een marktprijs moeten kennen wat vergelijkbaar is met laten we zeggen wat offshoring naar Roemenië zou kosten (ongeveer 30 Euro per uur)

Ik zou graag enige nuance willen aangeven in deze genuanceerde column.
Ik ben het geheel eens met de observaties 1,2,3 en 5.
Zeker mbt observatie 3 gaat management vaak in fout.
Een voorbeeld bij een grote multinational in het zuiden van het land toonde het volgende aan. Obv neutrale toewijzing van programmeerwerk werden programma's toegewezen aan een onshore en een offshore team. Het werk van het onshore team werd in een-vijfde van de tijd van het offshore team gedaan. Aangezien het offshore team een-derde kostte van het onshore team, werden de offshore programma's toch nog twee-derde duurder.
Tevens wordt er vaak vergeten dat de coordinatie en uitleg en ontwerp specificaties veel uitgebreider moeten worden gedaan. Zeker met een offshore team in India.
Mbt observatie 4 ben ik het geheel oneens, omdat zeker in het geval van India het zo is dat mensen daar zeer snel van job en werkgever veranderen, waardoor er zeer veel en heel snel kennis verdwijnt bij het offshore team. Tja, goedkoop is duurkoop. Tevens is het zo dat er veel mensen werken die niet geheel eerlijk zijn geweest op hun CV.
Het gevolg is dat er wel voldoende kennis is voor lage complexiteits programma's, maar niet voor hoge complexiteit programma's. Dus het offshore laten doen voor minder complexe programma's kan werken, maar over het algemeen gaat er heel vaak veel mis met hoge complexiteit programma's. Veelal wordt er dan ook voor dit werk uiteindelijk een onshore team erbij gehaald.
Maar het uiteindelijke echte probleem is dat IT Managers slechts worden beoordeeld op kosten en niet echt op andere. Dus, een business case ziet er goed uit. En dan zorgen ze er meestal wel voor dat tegen de tijd dat het duidelijk wordt dat de resultaten uit de business case niet gehaald worden, ze alweer weg zijn van hun toenmalige positie en er dus geen rekenschap kan worden gegeven.
Met andere woorden, de performance measures werken averechts ten opzichte van de doelstellingen van de onderneming en kunnen zelfs leiden tot perverse ontwikkelingen.
Er is nu al een langzame trend waarneembaar van het terughalen van offshore programma's.

Ik ben het niet eens met observatie 5 : "De geschiedenis laat tevens zien dat wanneer arbeid zich verplaatst naar andere werelddelen hiervoor andere arbeid terugkomt. Vaak van een hoogwaardiger kennisniveau dan daarvoor overigens. Ook voor it-offshoring is dat het geval. "

en zou graag van Dhr. van Solingen willen weten waar deze uitspraken precies op gebaseerd zijn. In het geval van Amerika komen er nauwelijks nieuwe jobs voor terug. Lees eens wat ons te wachten staat : http://seekingalpha.com/article/237383-offshoring-s-toll-it-to-endure-jobless-recovery-through-2014

Opmerkingen die ik in het artikel een beetje mis:

1) Offshoring van ICT-bouw leidt vaak niet tot kostenbesparing vanwege de redenen die Eric hierboven heeft beschreven. Dus 4 maal goedkopere uurtarieven tegen 5 maal lagere productiviteit.

2) De winst zit dan vooral in het beschikbaar hebben van extra handjes. Dus resources die we op de eigen arbeidsmarkt niet kunnen vinden. Dus over banenverlies hoef je je dan eigenlijk ook geen zorgen te maken.

3) Andere winst is dat we soms bij tenders meeliften met de CMMI maturity level 5 van een off-shore bedrijf. Allen weten we natuurlijk wel dat dit nergens op slaat (zowel het werkelijk nog steeds level 5 zijn, als dat we er op meeliften), maar toch.

4) Slechts 0.25% van projectkosten komt op conto van de bouwers komen (0.25% specs, 0.25% test en 0.25% rest). Dus nog minder effect op kosten dan we wel denken.

5). De schrijver noemt de term agile development onterecht. In het spectrum agile-formal moet je in zo'n situatie meer aan de formal kant zitten. Immers, geen van de 4 kernwaarden van agile development zou ik voleldig aanraden in een off-shore situatie. Alleen enkele van de 12 principes zijn van toepassing zoals iteratief werken en elke iteratie werkende software opleveren. Dat klinkt overigens veel makkelijker dan het is, dus zeker in off-shore situaies kost dat veel tijd. Net zo belangrijk als werkende goed geteste software is het in een off-shore situatie om voldoende te documenteren, een traceerbare software keren te hebben, uniform te programmeren, goed te unittesten, etc. Het zelfde verhaal geldt voor goed getrainde mensen mensen versus een goed proces en goede tooling. ook hier zijn beide even belangrijk en moet je zeker niet aan de agile kant gaan hangen.

Tom,
1) productiviteit 1:1 is gemakkelijk haalbaar (mits je daar wel strak op stuurt). Er kan wel wat overhead zijn in communicatie (max 10%), maar daar staat een besparing in PM taken tegenover (die doe je nl ook gewoon offshore).
2) geen extra handjes, maar 100% geintegreerd in je oplossing. Pas dan haal je voordelen. Als je pas na gaat denken over offshoring als je handjes tekort komt snap ik het productiviteitsverhaal ineens helemaal.
3)Het CMM level 5 verhaal gooi maar in je pet. Waar het om gaat is dat je integrale werkafspraken (processen, tooling, rapportages) enz. afspreekt. Beetje strak regelen kan geen kwaad, maar level 5 hoeft echt niet altijd.
4)Je moet ook niet alleen de bouw offshoren, maar elke activiteit die maar denkbaar is. Op het gehele project is 75% makkelijk haalbaar. Dus wel zeker kosten efficient. Dus vanaf dag 1 offshoren: requirements, design, test, deploy, run en zelfs PM taken, QA, PMO, enz.
5) Agile/Scrum, Waterval, Iteratief, RUP allemaal mogelijk met offshore. Basisprincipe is goed verstand en duidelijke afspraken: je moet wel dezelfde taal spreken. De methode is ondergeschikt vaak, al zou ik bij Waterval wel wat ijkmomenten inlassen :-)

@Johan: Daar zat ik ook laatst aan te denken.

Ze zijn daar zo goedkoop omdat eten en wonen daar zo gigantisch goedkoop is.

Over de dienstverlening moeten ze geen invoerrechten betalen? Beetje raar..

Toenemende complexiteit:

Iedere sales weet hoe moelijk het is te communiceren met andere culturen.

Communicatie tussen verschillende disciplines is al lastiger. De business die iets wil laten doen door de eigen it-ers. Voordat iedereen elkaar begrijpt, moet er vaak behoorlijk energie in worden gestoken.

Communicatie binnen een complex project, is weer iets moeilijker.

Interculturele communicatie met internationale contacten in andere tijdzones binnen een complex project, is nog veel moeilijker. Dat moet je liever niet willen. Tijdrovend, veel minder kans op succes, veel te lastig voor ongeveer alle partijen... hoewel een derde wereld partij het tegendeel zal betogen... Natuurlijk. Iedereen wil de buik vullen. Maar zit je als manager nu echt te wachten op een systeem op 3e wereld niveau? Wil je echt je veilige bolide inruilen tegen het goedkopere, zeer goed ogende model uit het verre dat echter bij de kleinste botsing geen spaan van je heel laat???

Aanvullend op de observaties 1, 3 en 4 van Rini van Solingen. In alle offshore trajecten die ik heb mogen ervaren was er sprake van virtuele product ontwikkeling, of in ander woorden een belangrijk deel van de offshore projecten wordt in het thuisland uitgevoerd (requirements engineering, ontwerpen/bepalen architectuur specificeren, testen e.d.). In bijna alle gevallen dat de kwaliteit tegen viel was dat te voorspellen aan de wijze waarop de knip tussen hier en offshore is gelegd en de wijze waarop gecommuniceerd wordt. Er wordt veel te vaak in oplossingen gecommuniceerd met de offshore partijen in plaats van de kracht van de offshore partijen te gebruiken om zelf de beste oplossing te ontwikkelen.

Als de offshore partij op een hoger CMMI niveau zit dan de lokale opdrachtgever (dat kan ook een lokale vestiging zijn van dezelfde leverancier) en er wordt in kant en klare specificaties gecommuniceerd dan kan de offshore partij niets anders dan exact maken wat is gevraagd, ook al is dat onlogisch en soms zelfs compleet fout. Ik heb eens gesproken met een Indiase quality manager en die bevestigde ooit mijn vermoeden dat uit specificaties de onderliggende requirements werden gedestilleerd. De specificaties waren vanwege de vele inconsistenties gewoonweg niet bruikbaar. Een belangrijk project met heel veel RfC's is daardoor volledig fout gegaan. In India konden ze gewoonweg het proces niet meer volgen en was er geen tijd om de RfC's uit alle gewijzigde specificaties te vissen.

Een ander bron van problemen bij virtuele product ontwikkeling is in 2007 beschreven in het proefschrift van Jacobs en Moll van de Universiteit Eindhoven. Zij identificeerden dat 60% van de problemen waren terug te voeren op configuration management, requirements management, systeem integratie, test strategie en testomgeving. Vooral overgangen van lifecycles van (sub)systemen werden als gevoelig voor defecten bevonden. Dus veelal zaken die lokaal geregeld dienen te worden.

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.