1. Inleiding

Twee decennia lang is het aanbod hetzelfde geweest en zag de rekensom er onweerstaanbaar uit. Een engineer in India kost een fractie van een in West-Europa of de Verenigde Staten, het aanbod ervan is groot en goed opgeleid, en Engels is de voertaal, dus een bedrijf dat zijn softwarewerk daarheen verplaatst zou, op papier, hetzelfde werk voor veel minder moeten doen. Een grote hoeveelheid werk is op precies die redenering verplaatst, en India heeft daarop een IT-dienstverleningssector van wereldklasse gebouwd. En toch zijn de resultaten, bedrijf voor bedrijf, opvallend ongelijk: sommige organisaties krijgen jarenlang uitstekende software uit India, terwijl andere een stijgende rekening krijgen, een dalende kwaliteit van levering, en een stroom defecten die de bespaarde salarissen nooit helemaal dekken, totdat zij offshoring een mislukking verklaren en het werk naar huis halen, vaak om te concluderen dat het probleem India was. Het was India niet.

Het probleem is dat bedrijven het verkeerde offshoren. De intuïtie achter offshoring is dat softwareontwikkeling uitvoering is, een hoeveelheid werk die in manuren gemeten kan worden en gekocht waar manuren het goedkoopst zijn, en op die intuïtie overhandigt een bedrijf een specificatie en een bezetting en wacht het op output. Maar softwareontwikkeling is niet voornamelijk uitvoering; het is het oplossen van duizend kleine ambiguïteiten, die elk vereisen dat men weet wat de business werkelijk bedoelde, hoe dit onderdeel in het geheel hoort te passen, en wat “klaar” hier echt betekent, en die kennis leeft waar de business is, niet waar de toetsenborden zijn. Wanneer een bedrijf de uitvoering offshoret, offshoret het onbewust ook die beslissingen, naar de mensen die het verst af staan van de context die nodig is om ze goed te nemen, en het resultaat is werk dat lokaal plausibel en globaal fout is, laat ontdekt, over een kloof van twaalf uur heen, en traag gecorrigeerd. De arbeidsarbitrage is reëel; de coördinatie en herbewerking die zij uitlokt zijn, slecht aangepakt, groter.

Dit artikel gaat over het operationele model dat de fout herstelt door haar niet te maken, en het model heeft een naam die wij overal zullen gebruiken: het onshore commandocentrum. Het idee is om, bewust en structureel, de twee dingen te scheiden die een naïeve offshoring op één hoop gooit. Het ene is uitvoering, het bouwen, dat werkelijk kan en zou moeten opschalen waar talent overvloedig en betaalbaar is, in India. Het andere is commando: beslissen wat gebouwd wordt en in welke volgorde, de architectuur en de interfaces tussen onderdelen in eigendom houden, omzetten wat de business vaag wil in een specificatie die precies genoeg is om ver weg gebouwd te worden zonder een gesprek, en beoordelen of wat terugkwam juist is. Commando is klein, senior en duur, en het blijft onshore, naast de business wiens intentie het bestaat om te dragen. De stelling is dat het succes van een offshoringprogramma vrijwel volledig wordt bepaald door de vraag of deze commandolaag bestaat en goed is, en nauwelijks door het ruwe vermogen van het offshoreteam, dat doorgaans prima is; en dat bedrijven falen door te weinig in commando te investeren, juist omdat commando het dure, onshore deel is dat offshoring zou moeten elimineren.

De bijdrage is een betoog en een klein model, geen benchmark. Paragraaf 2 plaatst de stelling tegen de staat van dienst van offshoring en wereldwijde software-engineering. Paragraaf 3 diagnosticeert het echte falen: verantwoordelijkheid offshoren in plaats van louter uitvoering. Paragraaf 4 beschrijft het commandocentrum en wat het in eigendom heeft. Paragraaf 5 geeft een model van waar de grens tussen commando en levering zou moeten vallen, draaiend om contextbelasting en specificatievolledigheid. Paragraaf 6 behandelt de klok, en hoe follow-the-sun hefboom wordt in plaats van latentie. Paragraaf 7 leidt de optimale commandoverhouding af. Paragraaf 8 volgt een geconstrueerde casus; de paragrafen 9 tot en met 12 trekken de consequenties, beantwoorden bezwaren, benoemen beperkingen en sluiten af. De vraag is overal: wat moet een bedrijf thuis houden, en hoeveel ervan, zodat het werk dat het naar India stuurt juist terugkomt?

2. Achtergrond

2.1 De staat van dienst van offshoring

De uitbesteding en offshoring van IT kent een van de grotere empirische literaturen in de informatiekunde, en haar oordeel is niet dat offshoring niet loont maar dat haar opbrengst afhangt van hoe zij gemanaged wordt. Lacity, Khan en Willcocks (2009), die twee decennia aan studies overzien, vinden dat de bekwaamheden van klant en leverancier, het contractontwerp en het relatiebeheer, in plaats van loonverschillen alleen, de spreiding tussen geslaagde en mislukte opdrachten verklaren. Carmel en Tjia (2005) gaven het praktijkverslag van sourcing bij een wereldwijd personeelsbestand en inventariseerden de manieren waarop afstand de arbitrage uitholt; Sahay, Nicholson en Krishna (2003) gaven het boeklange verslag van softwareontwikkeling over de Indiase grens heen, en Oshri, Kotlarsky en Willcocks (2007) traceerden hoe een toonaangevende Indiase leverancier een global delivery model rond verspreide expertise organiseerde. Rottman en Lacity (2006) destilleerden bewezen praktijken en vonden dat de bedrijven die slaagden fors investeerden in het onshore werk van specificeren, coördineren en besturen, precies het werk dat dit artikel commando noemt. De consistente bevinding is dat de besparing bruto is, niet netto, en dat wat tussen beide staat managementinspanning is die grotendeels thuis blijft.

2.2 Waarom afstand duur is

Een tweede literatuur, over wereldwijd gedistribueerde softwareontwikkeling, verklaart het mechanisme. Herbsleb en Mockus (2003), in de studie die het meest centraal staat in dit artikel, toonden empirisch aan dat werkitems waarvoor mensen op meerdere locaties nodig zijn aanzienlijk langer duurden om te voltooien dan vergelijkbare items op één locatie, en herleidden de vertraging tot de kosten en latentie van de communicatie die coördinatie over locaties heen vereist. Ramasubbu en Balan (2007), die projecten bestudeerden die verspreid waren tussen India en de Verenigde Staten, maten dezelfde boete rechtstreeks in projectprestaties. Olson en Olson (2000) gaven het algemene resultaat onder de titel “distance matters”: werk op één locatie profiteert van snelle, rijke, informele communicatie die gedistribueerd werk verliest, en geen enkel gereedschap herstelt dat volledig. Kraut en Streeter (1995) hadden al laten zien hoeveel van softwareontwikkeling coördinatie is in plaats van coderen, en Brooks (1975) had lang daarvoor de reden gegeven waarom mensen toevoegen aan gedistribueerd werk het kan vertragen: communicatiepaden groeien sneller dan de mensen. De les is niet dat gedistribueerde ontwikkeling niet kan werken, maar dat elke grens die een stuk werk moet oversteken een prijs heeft, en de prijs wordt betaald in tijd en defecten.

2.3 De wet van Conway en de architectuur van de grens

Het diepste idee waarop het artikel leunt is dat van Conway (1968): de structuur van een systeem gaat de communicatiestructuur weerspiegelen van de organisatie die het bouwt. De corollair ervan voor offshoring is exact en onderbenut. Als offshore en onshore twee losjes communicerende groepen zijn, dan zal de software het schoonst zijn wanneer de grens daartussen langs een werkelijke architecturale naad valt, een module met een gedefinieerde interface, en zal zij het meest problematisch zijn waar één strak gekoppelde brok werk over de kloof heen wordt gesplitst. Herbsleb en Grinter (1999) bevestigden dit rechtstreeks, en vonden dat gedistribueerde ontwikkeling slaagt wanneer de architectuur modulair genoeg is dat elke locatie een deel in eigendom heeft en de interfaces tussen de delen expliciet zijn, en worstelt wanneer dat niet zo is. Parnas (1972) gaf de ontwerpdiscipline, information hiding, die zulke modules mogelijk maakt. De praktische consequentie, uitgewerkt in paragraaf 4, is dat het in eigendom houden van de architectuur niet een van de taken van het commandocentrum onder vele is; het is de taak die alle andere mogelijk maakt, omdat zij beslist waar de dure grens valt.

3. Het echte falen: verantwoordelijkheid offshoren

Het kenmerkende falen van offshoring is niet traag typen; het is werk dat zelfverzekerd af is en stilletjes fout. Een requirement wordt overgedragen dat compleet is in het hoofd van de verzender en ambigu op papier, omdat de verzender een context deelt met de business die de ontvanger niet heeft. De offshore-engineer, bekwaam en bereidwillig, lost de ambiguïteit op de enige manier op die vanaf twaalf tijdzones afstand beschikbaar is: door redelijk te gokken en te bouwen. De gok blijkt fout bij de acceptatie, als er acceptatie is, of in productie, als die er niet is, en de correctie steekt de kloof tweemaal over, eenmaal om uit te leggen en eenmaal om te verifiëren, elke oversteek een dag verloren aan de klok. Vermenigvuldig dit met elke ambiguïteit in een echt systeem en de arbitrage is verdwenen, niet omdat iemand iets incompetents deed, maar omdat de beslissingen die context nodig hadden genomen werden waar die er niet was.

Wat er gebeurd is, in de taal van dit artikel, is dat het bedrijf verantwoordelijkheid offshorede terwijl het alleen uitvoering wilde offshoren. Verantwoordelijkheid voor een stuk software is het opgebouwde gezag om de ambiguïteiten ervan juist op te lossen: weten wat de business bedoelde, beslissen hoe het deel het geheel dient, zeggen wat “juist” is. Dat gezag is onlosmakelijk verbonden met context, en context is lokaal. Uitvoering, het bouwen van een ding zodra de ambiguïteiten ervan opgelost zijn, is niet contextgebonden en reist goed. De fout is om beide als één pakket te behandelen en ze samen te versturen; het herstel is om ze te splitsen, verantwoordelijkheid onshore te houden waar haar context leeft, en alleen uitvoering offshore te sturen, met haar ambiguïteiten reeds opgelost tot specificatie. Al het volgende is een uitwerking van hoe die splitsing te maken en waar.

4. Het commandocentrum

Het onshore commandocentrum is het organisatorische thuis van de verantwoordelijkheid die niet mag reizen. Het is bewust klein en bewust senior, omdat zijn hefboom voortkomt uit de kwaliteit van een paar beslissingen in plaats van de hoeveelheid output, en het zit naast de business, niet naast de toetsenborden. Figuur 1 tekent het model en tabel 3 verdeelt de arbeid. Het commandocentrum heeft vijf dingen in eigendom, en de discipline van het model is dat het alle vijf in eigendom heeft en probeert niets anders in eigendom te hebben.

Van intentie naar specificatie. Het eerste product van het commandocentrum is geen software maar specificatie: de vertaling van wat de business vaag wil in een beschrijving die precies genoeg is om gebouwd te worden door iemand die niet even kan overleunen en vragen. Dit is het werk dat ambiguïteit oplost waar de context is, zodat er geen opgelost hoeft te worden waar die niet is, en het is de activiteit met de allerhoogste hefboomwerking in het hele model, omdat elke ambiguïteit die in een specificatie achterblijft later betaald wordt tegen de volle kosten van een heen-en-weerreis over de kloof.

Architectuur en interfaces. Volgens de wet van Conway zal de software breken langs de communicatienaden van de organisatie, dus heeft het commandocentrum de architectuur in eigendom juist om te kiezen waar die naden vallen: het ontleedt het systeem in modules met expliciete interfaces zodat elke offshore-pod een deel in eigendom heeft dat het met weinig grensoverschrijdende afhankelijkheden kan bouwen. De grens goed trekken is wat afstand omzet van een belasting die op elke interactie wordt betaald naar een belasting die slechts op enkele welomschreven interfaces wordt betaald.

Prioritering. Wat eerst gebouwd wordt is een oordeel van de business, niet van de levering, en het blijft bij het commandocentrum, dat de enige backlog en de volgorde ervan bewaakt. Het verspreiden van prioritering naar het offshoreteam, of naar meerdere belanghebbenden tegelijk, herintroduceert over de kloof heen precies de coördinatie die het model bestaat om in te dammen.

Acceptatie en de kwaliteitspoort. Het commandocentrum beslist wat “klaar” is en toetst het teruggekeerde werk daaraan, en bewaakt een poort die de business vertrouwt. Dit is de tegenhanger van specificatie: nadat het vooraf de juistheid heeft gedefinieerd, verifieert het die bij terugkeer, en omdat het onshore en dicht bij de business is kan het geschiktheid beoordelen, niet louter functie.

Eén verantwoordelijke eigenaar. Ten slotte is het commandocentrum de plek waar de verantwoording onverdeeld is: één eigenaar die aan de business verantwoording aflegt voor wat geleverd wordt, en die niet over de kloof kan wijzen. Verantwoording die over de grens gesplitst is, is verantwoording die zoek is geraakt, en haar terugbrengen naar één onshore punt is een groot deel van wat het model bestuurbaar maakt.

5. De grens trekken

Als commando onshore blijft en uitvoering offshore gaat, draait alles om waar de grens daartussen getrokken wordt, taak voor taak. Het model dat de keuze bestuurt heeft twee assen. De eerste is de contextbelasting van een taak: hoeveel lokale, impliciete, bedrijfsspecifieke kennis het juist oplossen ervan vereist, hoog voor een wijziging die een subtiele regelgevingsregel of een langlopende klanttoezegging raakt, laag voor een goed afgebakend component met een duidelijk contract. De tweede is de specificatievolledigheid die het commandocentrum eraan kan geven: hoe volledig de ambiguïteiten ervan vooraf, op papier, zonder gesprek opgelost kunnen worden. Een taak is veilig te offshoren wanneer de resterende ambiguïteit die de offshore-pod bereikt, de contextbelasting ervan na aftrek van de erop toegepaste specificatievolledigheid, klein is. Schrijven wij $\kappa$ voor contextbelasting en $s$ voor specificatievolledigheid, beide op een gemeenschappelijke schaal, dan is het residu

en het is $\alpha$, niet de ruwe moeilijkheid van het werk, die herbewerking voorspelt. Het model kent een scherpe bestuurlijke lezing, getekend in tabel 1. Een taak met weinig context offshoret schoon, wat haar technische moeilijkheid ook is. Een taak met veel context is niet ongeschikt voor offshoring; zij is ongeschikt voor offshoring ongespecificeerd, en de taak van het commandocentrum is om $s$ te verhogen totdat $\alpha$ klein genoeg is om te versturen. Waar de contextbelasting werkelijk onherleidbaar is, waar de kennis helemaal niet opgeschreven kan worden, blijft de taak onshore, en dat eerlijk erkennen is deel van de discipline. De faalvorm die het model benoemt is de taak met veel context die verstuurd wordt met een specificatie van lage volledigheid: maximale resterende ambiguïteit, offshore opgelost door giswerk, op maximale afstand.

6. De klok

Het tijdverschil tussen een westers bedrijf en India, zo’n negen tot twaalf uur, is het kenmerk dat beoefenaars het vaakst als een zuivere last behandelen en het kenmerk dat het commandocentrum het schoonst in een troef kan omzetten. Onverzorgd is de kloof latentie: een vraag die aan het einde van de offshore-dag gesteld wordt, wordt aan het einde van de onshore-dag beantwoord, en één enkele verduidelijking kost een kalenderdag wat haar inhoud ook is, dus een keten van verduidelijkingen kost een week om een uur echte inhoud op te lossen. Dit is het mechanisme waardoor slecht uitgevoerde offshoring traag aanvoelt, zelfs wanneer iedereen hard werkt: het kritieke pad loopt door de kloof, en de kloof voegt een dag per oversteek toe.

Goed uitgevoerd is dezelfde kloof een tweede ploeg. Als het commandocentrum werk overdraagt waarvan de ambiguïteiten al opgelost zijn, voeren de offshore-pods het door de onshore-nacht heen uit en leveren zij de resultaten tegen de onshore-ochtend, en de dag waar de business doorheen slaapt is een dag van voortgang in plaats van een dag van wachten. Het verschil tussen de twee uitkomsten is volledig de resterende ambiguïteit $\alpha$ van wat overgedragen wordt: een overdracht met $\alpha \approx 0$ heeft geen heen-en-weerreis nodig en de klok is zuivere winst; een overdracht vol onopgeloste vragen keert de klok tegen je, omdat elke vraag een volle dag is. Een grove manier om het te zien is dat de effectieve versnelling van de tweede ploeg is

waar $\eta$ meet hoe schoon werk overgedragen kan worden en $\alpha$ de resterende ambiguïteit van vergelijking (1) is; naarmate $\alpha\to 0$ nadert de klok een werkelijke extra ploeg, en naarmate $\alpha$ stijgt stort de winst in en keert vervolgens om in de belasting van een dag per vraag. Het commandocentrum verdient de klok door de specificatie en de definitie van klaar in eigendom te houden die $\alpha$ klein maken, en daarom is follow-the-sun een gevolg van goed commando, geen planningstruc die apart gekocht kan worden.

7. De commandoverhouding

Hoeveel commando is genoeg? De vraag heeft een echt antwoord, en het is noch “zo weinig mogelijk”, het instinct dat gooi-het-over-de-muur-offshoring voortbrengt, noch “zoveel mogelijk”, wat onshore de kosten herbouwt die offshoring moest afwerpen. Laat $r$ de commandoverhouding zijn, de capaciteit van het onshore commandocentrum als fractie van de offshore leveringscapaciteit die het bestuurt. Commando kost het hoge onshore tarief $w_c$ per eenheid; levering kost het lage offshore tarief $w_o$ per eenheid. De waarde van commando is dat het de resterende ambiguïteit verlaagt die de pods bereikt en daarmee de herbewerking die zij moeten doen: meer commando betekent meer werk dat gespecificeerd, beoordeeld en gepoort wordt voor en nadat het de kloof oversteekt, en dus een lagere herbewerkingsvermenigvuldiger op het geleverde werk. Een bruikbare vorm voor die vermenigvuldiger is

waar $a$ de herbewerking schaalt die helemaal geen commando zou oplopen, bepaald door de intrinsieke ambiguïteit van het werk, en $b$ meet hoe effectief commando zich omzet in opgeloste ambiguïteit. De totale kosten van het leveren van één eenheid afgewerkt werk, commando plus herbewerkte levering, zijn dan

een som van een stijgende term, de kosten van commando, en een dalende, de herbewerking die commando voorkomt, zodat het een enkel inwendig minimum heeft. $C'(r)=0$ stellen geeft de kostenminimaliserende commandoverhouding

wat het centrale kwantitatieve resultaat van het artikel is. Het zegt drie dingen waar een manager naar kan handelen. De optimale hoeveelheid commando is positief: $r^\ast > 0$ zodra $w_o a b > w_c$, dat wil zeggen zodra commando enigszins effectief is en ambiguïteit enigszins reëel, dus het werk over de muur gooien ($r = 0$) is nooit optimaal. Zij is eindig: commando voorbij $r^\ast$ kost meer dan de herbewerking die het bespaart, dus alles onshore houden is evenmin optimaal. En zij beweegt de goede kant op: $r^\ast$ stijgt met de ambiguïteit van het werk ($a$) en met hoe goed commando die oplost ($b$), en daalt naarmate onshore commando duur wordt ten opzichte van offshore levering ($w_c/w_o$), dus ambigue portefeuilles met veel context rechtvaardigen een dikkere commandolaag en eenvoudige, goed afgebakende een dunnere. Figuur 2 tekent $C(r)$ en de twee faalregimes aan weerszijden van het optimum.

8. Een geconstrueerde casus

De casus is geconstrueerd, niet waargenomen: de cijfers zijn illustratief en intern consistent, en het is bedoeld om de grootheden van het model plausibele waarden te laten aannemen in plaats van een resultaat te rapporteren. Een westerse groep voert applicatieontwikkeling uit voor haar backoffice-systemen en offshorede, drie jaar geleden, het grootste deel ervan naar een leverancier in India op basis van staff augmentation: zij hield een handvol onshore projectmanagers aan, schreef requirements in de vorm die zij altijd had gehanteerd, en mat succes af aan de verplaatste formatie en het bespaarde dagtarief. Op papier had zij de kosten van een ontwikkelaar gehalveerd. In de praktijk was de doorlooptijd van een feature, van aanvraag tot geaccepteerde productiewijziging, langer geworden, was het percentage ontsnapte defecten naar productie gestegen, en ging een groot en groeiend deel van de uren van het offshoreteam op aan het herbewerken van features die gebouwd waren naar een redelijke maar foute lezing van een ambigu requirement. De besparing was bruto; netto was zij dun en dalend. Tabel 2 geeft de kolom van vóór.

De groep bouwde de opdracht vervolgens opnieuw op rond een commandocentrum. Zij veranderde niet van leverancier en haalde geen werk naar huis; zij voegde een dunne, senior onshore laag toe, een paar procent van de totale formatie, die eigenaarschap nam over de vijf dingen van paragraaf 4: zij herschreef requirements als specificaties met expliciete acceptatiecriteria, hersneed de architectuur zodat elke offshore-pod een module achter een gedefinieerde interface in eigendom had, bewaakte één geordende backlog, en liet een acceptatiepoort lopen voordat iets de productie bereikte. Het offshoreteam en zijn tarieven bleven ongewijzigd; wat veranderde was de resterende ambiguïteit $\alpha$ die het bereikte. De herbewerking daalde naarmate specificaties het giswerk oplosten dat haar had aangedreven, het percentage ontsnapte defecten daalde naarmate de poort ving wat de kloof voorheen verborg, en de klok keerde van latentie in een tweede ploeg naarmate overdrachten geen heen-en-weerreizen meer nodig hadden. De kosten van het toegevoegde commando waren een fractie van de herbewerking die het wegnam, wat vergelijking (5) in de praktijk is: de opdracht had ver links van $r^\ast$ gedraaid, en ernaartoe bewegen verlaagde de totale kosten ook al verhoogde het de onshore kosten. Tabel 2 volgt de verandering.

9. Wat er verandert voor het operationele model

Het commandocentrum omarmen verandert waar een bedrijf goed in moet zijn, en de verandering is ongemakkelijk omdat zij indruist tegen het instinct dat offshoring motiveerde. De besparing is nog steeds reëel, maar zij wordt alleen binnengehaald door, onshore en tegen seniortarieven, te besteden aan de commandolaag die de naïeve businesscase als te elimineren verspilling behandelde. Tabel 3 zet de arbeidsverdeling uiteen die het model vereist. De schaarse hulpbron wordt het handvol senior mensen dat intentie, architectuur en acceptatie goed kan dragen, en de offshoringcapaciteit van een bedrijf wordt begrensd door hoeveel van zulke mensen het heeft, niet door hoeveel offshore-engineers het kan aannemen. De metriek verandert ook: verplaatste formatie en bespaard dagtarief, de cijfers die gooi-het-over-de-muur-offshoring er goed laten uitzien, worden vervangen door de doorlooptijd van features, het ontsnappen van defecten en het aandeel offshore-uren besteed aan herbewerking, de cijfers die onthullen of commando zijn werk doet.

Er is een tweede verschuiving, in waar de senioriteit zit. Gooi-het-over-de-muur-offshoring neigt ertoe het interessante, senior werk samen met de rest offshore te sturen en een junior coördinatielaag thuis te houden; het commandocentrummodel keert dat om, door de senioriteit onshore te houden waar de context is en het offshoreteam uitstekend te laten zijn in uitvoering zonder dat het gevraagd wordt context te leveren die het niet kan hebben. Dit wordt vaak verkeerd gelezen als wantrouwen jegens het offshoreteam. Het is het tegendeel: het is de opzet die een bekwaam offshoreteam zijn beste werk laat doen, door het niet te vragen ambiguïteiten op te lossen die niemand op zijn afstand goed zou kunnen oplossen, en door het specificaties te geven die duidelijk genoeg zijn dat zijn competentie aan bouwen besteed wordt in plaats van aan gokken.

10. Bezwaren en antwoorden

Het commandocentrum voegt alleen onshore kosten toe en holt de besparing uit. Het voegt onshore kosten toe en verhoogt de nettobesparing, wat de hele pointe van vergelijking (5) is: de meeste mislukkende opdrachten zitten ver links van $r^\ast$, waar een beetje meer commando veel meer herbewerking wegneemt dan het kost. Het commandocentrum is geen overhead op de besparing; het is het mechanisme dat een brutobesparing omzet in een nettobesparing. Een bedrijf dat werkelijk al op $r^\ast$ zit zou geen commando moeten toevoegen; vrijwel geen enkel bedrijf zit daar.

Als je alles zo precies moet specificeren, waarom bouw je het dan niet gewoon onshore? Omdat specificatie en bouw zeer verschillende kosten en zeer verschillende schaarstes hebben. Specificatie is een kleine hoeveelheid senior, contextgebonden werk; bouw is een grote hoeveelheid werk dat eenmaal gespecificeerd niet contextgebonden is. Het model stuurt de grote, goedkoop te plaatsen hoeveelheid naar waar zij betaalbaar is en houdt alleen de kleine, contextgebonden hoeveelheid thuis. De twee weer samenvoegen geeft precies de arbitrage op die reëel is.

Moderne gereedschappen en videogesprekken hebben afstand irrelevant gemaakt. Zij hebben haar kleiner gemaakt, niet irrelevant, en het bewijs dat afstand nog steeds telt is robuust (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Gereedschap verlaagt de kosten van een oversteek; het neemt de dag niet weg die de klok aan een heen-en-weerreis toevoegt, noch herstelt het de informele, omgevende communicatie die teams op één locatie gebruiken om ambiguïteit op te lossen zonder het te merken. Het commandocentrum is het structurele antwoord dat gereedschap aanvult maar niet vervangt.

Onze offshorepartner is zeer bekwaam en kan het geheel in eigendom nemen. Bekwaamheid is niet het probleem; context wel. Een zeer bekwaam offshoreteam kan nog steeds geen ambiguïteit oplossen waarvan de oplossing vereist dat men weet wat de business bedoelde, en het dat vragen zet zijn competentie tegenover een probleem dat afstand onoplosbaar maakt. Het model houdt verantwoordelijkheid onshore niet omdat het offshoreteam zwak is, maar omdat verantwoordelijkheid gebonden is aan een context die onshore is.

11. Beperkingen

Dit is een op de praktijk gericht betoog met een bewust eenvoudig model, en de beperkingen ervan horen duidelijk te zijn. Het model van de paragrafen 5 tot en met 7 is illustratief: de vorm van resterende ambiguïteit van vergelijking (1), de exponentiële herbewerkingsvermenigvuldiger van vergelijking (3) en de enkele optimale verhouding van vergelijking (5) zijn vereenvoudigingen gekozen omwille van de leesbaarheid, en de constanten $a$, $b$, $w_c$ en $w_o$ worden hier niet gemeten; een bedrijf kan ze schatten uit zijn eigen herbewerkings- en tariefgegevens, en wij zouden verwachten dat de kwalitatieve vorm, een inwendig optimum dat meebeweegt met ambiguïteit en relatieve kosten, standhoudt zelfs waar de exacte vorm dat niet doet. Het betoog is afgebakend tot werk waarvan de ambiguïteiten, met inspanning, tot specificatie opgelost kunnen worden; werk dat werkelijk op onderzoek lijkt, waar nog niemand weet wat juist is, past slecht in het model en zou grotendeels op één locatie moeten blijven. Het artikel put uit India omdat daar de diepte van het aanbod en de schaal van de praktijk zijn, maar niets in het model is specifiek voor een land; het geldt voor elke onshore–offshore splitsing over een echte afstand en klok. En het model veronderstelt een bedrijf dat überhaupt in staat is een senior commandolaag te bemensen; een bedrijf dat dat niet kan zou eerlijk moeten zijn dat het nog niet in staat is goed te offshoren, in plaats van slecht te offshoren en het resultaat een oordeel over India te noemen.

12. Conclusie

Het offshoren van IT-werk naar India stelt bedrijven teleur die het verkeerde offshoren: zij sturen de verantwoordelijkheid samen met de uitvoering de deur uit, maken het werk los van de context en het oordeel die het juist maken, en zien vervolgens herbewerking en de klok de besparing verslinden waarvoor zij kwamen. Het herstel is niet om het werk naar huis te halen maar om het juist te splitsen, door onshore het dunne, senior commando te houden dat naast de business moet blijven, beslissen wat gebouwd wordt, de architectuur en de interfaces in eigendom houden, intentie omzetten in specificatie, en de acceptatie bewaken, terwijl de uitvoering opschaalt in India waar talent overvloedig en betaalbaar is. Waar de grens te trekken is een vraag die de resterende ambiguïteit van een taak beantwoordt, en het vakmanschap van het commandocentrum is om de specificatie te verhogen totdat die ambiguïteit klein genoeg is om de kloof over te steken; hoeveel commando te behouden is een vraag met een echt optimum, positief en eindig, dat stijgt met de ambiguïteit van het werk en daalt naarmate commando duur wordt. Op deze manier gedaan houdt de afstand op een belasting te zijn en wordt de klok van twaalf uur een tweede ploeg, en wordt de arbitrage die altijd reëel was eindelijk behouden. Offshore het bouwen; commandeer het vanuit huis. Een bedrijf dat onthoudt welke van de twee gebonden is aan context, en welke niet, kan offshoring naar India beheersen; een bedrijf dat het vergeet zal blijven concluderen, ten onrechte, dat het probleem het andere eind van de lijn was.

Bijlage A. Een commandocentrum opzetten

De praktijken hieronder zijn wat de splitsing van paragraaf 4 in de praktijk standhoudt. Geen ervan is nieuw; de discipline is de waarde.

Referenties

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley. ISBN 978-0-201-83595-3. (Original work published 1975.)

Carmel, E. (1999). Global software teams: Collaborating across borders and time zones. Prentice Hall. ISBN 978-0-13-924218-6.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22–29. https://doi.org/10.1109/52.914734

Carmel, E., & Tjia, P. (2005). Offshoring information technology: Sourcing and outsourcing to a global workforce. Cambridge University Press. ISBN 978-0-521-84355-4.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Herbsleb, J. D., & Grinter, R. E. (1999). Splitting the organization and integrating the code: Conway’s law revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE) (pp. 85–95). ACM. https://doi.org/10.1145/302405.302455

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. https://doi.org/10.1145/203330.203345

Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 47(4), 62–66. https://doi.org/10.1145/975817.975818

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. https://doi.org/10.1016/j.jsis.2009.06.002

Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. https://doi.org/10.1145/174666.174668

Olson, G. M., & Olson, J. S. (2000). Distance matters. Human–Computer Interaction, 15(2–3), 139–178. https://doi.org/10.1207/S15327051HCI1523_4

Oshri, I., Kotlarsky, J., & Willcocks, L. P. (2007). Managing dispersed expertise in IT offshore outsourcing: Lessons from Tata Consultancy Services. MIS Quarterly Executive, 6(2), 53–65. https://aisel.aisnet.org/misqe/vol6/iss2/3/

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Ramasubbu, N., & Balan, R. K. (2007). Globally distributed software development project performance: An empirical analysis. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007) (pp. 125–134). ACM. https://doi.org/10.1145/1287624.1287643

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56–63. https://sloanreview.mit.edu/article/proven-practices-for-effectively-offshoring-it-work/

Sahay, S., Nicholson, B., & Krishna, S. (2003). Global IT outsourcing: Software development across borders. Cambridge University Press. ISBN 978-0-521-81604-5.