1. Introduktion

Under två decennier har erbjudandet varit detsamma och aritmetiken har sett oemotståndlig ut. En ingenjör i Indien kostar en bråkdel av en i Västeuropa eller USA, tillgången på dem är stor och välutbildad, och engelska är arbetsspråket, så ett företag som flyttar sitt mjukvaruarbete dit borde, på pappret, utföra samma arbete för mycket mindre. En stor mängd arbete har flyttats på exakt det resonemanget, och Indien har byggt en IT-tjänsteindustri i världsklass på det. Och ändå är resultaten, företag för företag, slående ojämna: vissa organisationer får utmärkt mjukvara från Indien i åratal, medan andra får en stigande räkning, en fallande leveranskvalitet och en ström av defekter som de sparade lönerna aldrig riktigt täcker, tills de förklarar offshoringen misslyckad och tar hem arbetet, ofta för att dra slutsatsen att problemet var Indien. Det var inte Indien.

Problemet är att företag offshorar fel sak. Intuitionen bakom offshoring är att mjukvaruutveckling är utförande, en kvantitet arbete som kan mätas i persontimmar och köpas där persontimmar är billigast, och på den intuitionen lämnar ett företag över en specifikation och en personalstyrka och väntar på output. Men mjukvaruutveckling är inte huvudsakligen utförande; det är upplösningen av tusen små tvetydigheter, som var och en kräver att man vet vad verksamheten faktiskt menade, hur denna del är tänkt att passa in i helheten och vad ”klart” verkligen betyder här, och den kunskapen bor där verksamheten är, inte där tangentborden är. När ett företag offshorar utförandet offshorar det omedvetet också dessa beslut, till de människor som är längst bort från den kontext som krävs för att fatta dem väl, och resultatet är arbete som är lokalt rimligt och globalt fel, upptäckt sent, över ett tolv timmars gap, och långsamt åtgärdat. Arbetskraftsarbitraget är verkligt; den koordinering och det omarbete det utlöser, illa hanterade, är större.

Detta dokument handlar om den driftsmodell som rättar misstaget genom att inte begå det, och modellen har ett namn som vi kommer att använda genomgående: kommandocentrumet på hemmaplan. Idén är att, avsiktligt och strukturellt, skilja de två ting som en naiv offshoring smälter samman. Det ena är utförandet, byggandet, som verkligen kan och bör skala där talangen är riklig och prisvärd, i Indien. Det andra är kommandot: att bestämma vad som ska byggas och i vilken ordning, att äga arkitekturen och gränssnitten mellan delarna, att förvandla det verksamheten vagt vill ha till en specifikation tillräckligt precis för att byggas långt borta utan ett samtal, och att bedöma om det som kom tillbaka är rätt. Kommandot är litet, seniort och dyrt, och det stannar på hemmaplan, intill den verksamhet vars avsikt det existerar för att bära. Tesen är att framgången för ett offshoringsprogram avgörs nästan helt av huruvida detta kommandoskikt existerar och är bra, och knappast alls av offshore-teamets råa förmåga, som vanligen är god; och att företag misslyckas genom att underinvestera i kommando just därför att kommandot är den dyra delen på hemmaplan som offshoring var tänkt att eliminera.

Bidraget är ett resonemang och en liten modell, inte en benchmark. Sektion 2 ställer påståendet mot offshoringens och den globala mjukvaruteknikens historik. Sektion 3 diagnostiserar det verkliga misslyckandet, att offshora ansvar snarare än enbart utförande. Sektion 4 beskriver kommandocentrumet och vad det äger. Sektion 5 ger en modell av var linjen mellan kommando och leverans bör falla, som vilar på kontextbelastning och specifikationsfullständighet. Sektion 6 behandlar klockan, och hur follow-the-sun blir en hävstång snarare än latens. Sektion 7 härleder det optimala kommandoförhållandet. Sektion 8 spårar ett konstruerat fall; sektionerna 9 till 12 drar konsekvenserna, bemöter invändningar, anger gränser och avslutar. Frågan genomgående är: vad måste ett företag behålla hemma, och hur mycket av det, för att det arbete det skickar till Indien ska komma tillbaka rätt?

2. Bakgrund

2.1 Offshoringens historik

Outsourcing och offshoring av IT har en av de större empiriska litteraturerna inom informationssystem, och dess utslag är inte att offshoring inte lönar sig utan att dess avkastning är beroende av hur den sköts. Lacity, Khan och Willcocks (2009), som går igenom två decenniers studier, finner att kundens och leverantörens förmågor, kontraktsutformning och relationshantering, snarare än löneskillnader allena, förklarar spridningen mellan framgångsrika och misslyckade uppdrag. Carmel och Tjia (2005) gav praktikerskildringen av sourcing till en global arbetskraft och katalogiserade de sätt på vilka avstånd eroderar arbitraget; Sahay, Nicholson och Krishna (2003) gav den boklånga skildringen av mjukvaruutveckling över Indiengränsen, och Oshri, Kotlarsky och Willcocks (2007) spårade hur en ledande indisk leverantör organiserade en global leveransmodell kring spridd expertis. Rottman och Lacity (2006) destillerade beprövade metoder och fann att de företag som lyckades investerade tungt i arbetet på hemmaplan med att specificera, koordinera och styra, just det arbete som detta dokument kallar kommando. Det konsekventa fyndet är att besparingen är brutto, inte netto, och att det som står mellan de två är ledningsinsats som till stor del stannar hemma.

2.2 Varför avstånd är dyrt

En andra litteratur, om globalt distribuerad mjukvaruutveckling, förklarar mekanismen. Herbsleb och Mockus (2003), i den studie som är mest central för detta dokument, visade empiriskt att arbetsmoment som krävde människor på flera platser tog väsentligt längre tid att slutföra än jämförbara moment på en enda plats, och härledde fördröjningen till kostnaden och latensen hos den kommunikation som koordinering mellan platser kräver. Ramasubbu och Balan (2007), som studerade projekt spridda mellan Indien och USA, mätte samma straff direkt i projektprestanda. Olson och Olson (2000) gav det allmänna resultatet under titeln ”distance matters”: samlokaliserat arbete drar nytta av snabb, rik, informell kommunikation som distribuerat arbete förlorar, och inget verktygsstöd återställer den helt. Kraut och Streeter (1995) hade redan visat hur mycket av mjukvaruutvecklingen som är koordinering snarare än kodning, och Brooks (1975) hade långt tidigare gett skälet till att tillägg av människor till distribuerat arbete kan sakta ner det: kommunikationsvägarna växer snabbare än människorna gör. Lärdomen är inte att distribuerad utveckling inte kan fungera utan att varje gräns ett arbetsstycke måste korsa har ett pris, och priset betalas i tid och defekter.

2.3 Conways lag och gränsens arkitektur

Den djupaste idén dokumentet lutar sig mot är Conways (1968): ett systems struktur kommer att spegla kommunikationsstrukturen hos den organisation som bygger det. Dess följdsats för offshoring är exakt och underutnyttjad. Om offshore och hemmaplan är två löst kommunicerande grupper, då blir mjukvaran renast när gränsen mellan dem faller längs en genuin arkitektonisk söm, en modul med ett definierat gränssnitt, och blir mest besvärlig där en enda hårt kopplad klump arbete delas över gapet. Herbsleb och Grinter (1999) bekräftade detta direkt, och fann att distribuerad utveckling lyckas när arkitekturen är tillräckligt modulär för att varje plats äger en del och gränssnitten mellan delarna är explicita, och kämpar när den inte är det. Parnas (1972) gav den designdisciplin, informationsdöljande, som gör sådana moduler möjliga. Den praktiska konsekvensen, utvecklad i sektion 4, är att det att äga arkitekturen inte är ett av kommandocentrumets många jobb; det är det jobb som gör alla de andra möjliga, eftersom det bestämmer var den dyra gränsen faller.

3. Det verkliga misslyckandet: att offshora ansvar

Det karaktäristiska offshoringsmisslyckandet är inte långsam skrivning; det är arbete som är självsäkert färdigt och i tysthet fel. Ett krav lämnas över som är fullständigt i avsändarens huvud och tvetydigt på pappret, eftersom avsändaren delar en kontext med verksamheten som mottagaren inte gör. Offshore-ingenjören, kompetent och villig, löser tvetydigheten på det enda sätt som är tillgängligt från tolv tidszoner bort: genom att gissa, rimligt, och bygga. Gissningen upptäcks vara fel vid acceptansen, om det finns en acceptans, eller i produktion, om det inte gör det, och rättelsen korsar gapet två gånger, en gång för att förklara och en gång för att verifiera, varje korsning en dag förlorad till klockan. Multiplicera detta med varje tvetydighet i ett verkligt system och arbitraget är borta, inte för att någon gjorde något inkompetent, utan för att de beslut som behövde kontext fattades där det inte fanns någon.

Vad som har hänt, på detta dokuments språk, är att företaget offshorade ansvaret när det menade att offshora endast utförandet. Ansvaret för en mjukvara är den ackumulerade befogenheten att lösa dess tvetydigheter korrekt: att veta vad verksamheten menade, att avgöra hur delen tjänar helheten, att säga vad ”korrekt” är. Den befogenheten är oskiljaktig från kontexten, och kontexten är lokal. Utförandet, konstruktionen av en sak när dess tvetydigheter väl är lösta, är inte kontextbundet och reser väl. Felet är att behandla de två som ett paket och skicka dem tillsammans; reparationen är att dela dem, behålla ansvaret på hemmaplan där dess kontext bor, och skicka offshore endast utförandet, med dess tvetydigheter redan upplösta i specifikation. Allt som följer är en utläggning av hur den delningen görs och var.

4. Kommandocentrumet

Kommandocentrumet på hemmaplan är det organisatoriska hemmet för det ansvar som inte får resa. Det är avsiktligt litet och avsiktligt seniort, eftersom dess hävstång kommer från kvaliteten hos några få beslut snarare än mängden output, och det sitter intill verksamheten, inte intill tangentborden. Figur 1 ritar modellen och tabell 3 delar arbetet. Kommandocentrumet äger fem ting, och modellens disciplin är att det äger alla fem och försöker äga inget annat.

Avsikt till specifikation. Kommandocentrumets första produkt är inte mjukvara utan specifikation: översättningen av det verksamheten vagt vill ha till en redogörelse tillräckligt precis för att byggas av någon som inte kan luta sig över och fråga. Detta är det arbete som löser tvetydighet där kontexten är, så att ingen behöver lösas där den inte är, och det är den enskilt mest hävstångsstarka aktiviteten i hela modellen, eftersom varje tvetydighet som lämnas kvar i en specifikation betalas för senare till den fulla kostnaden av en tur och retur över gapet.

Arkitektur och gränssnitt. Enligt Conways lag kommer mjukvaran att spricka längs organisationens kommunikationssömmar, så kommandocentrumet äger arkitekturen just för att välja var dessa sömmar faller: det bryter ner systemet i moduler med explicita gränssnitt så att varje offshore-pod äger en del som den kan bygga med få beroenden över gränsen. Att dra gränsen väl är vad som omvandlar avstånd från en skatt betald vid varje interaktion till en skatt betald endast vid några få väldefinierade gränssnitt.

Prioritering. Vad som byggs först är en affärsbedömning, inte en leveransbedömning, och den stannar hos kommandocentrumet, som håller den enda backloggen och dess ordning. Att sprida prioriteringen till offshore-teamet, eller till flera intressenter samtidigt, återinför över gapet precis den koordinering som modellen existerar för att hålla i schack.

Acceptans och kvalitetsgrinden. Kommandocentrumet bestämmer vad ”klart” är och prövar det återlämnade arbetet mot det, och håller en grind som verksamheten litar på. Detta är specifikationens motstycke: efter att ha definierat korrekthet i förväg verifierar det den vid återlämningen, och eftersom det är på hemmaplan och nära verksamheten kan det bedöma lämplighet, inte enbart funktion.

En ansvarig ägare. Slutligen är kommandocentrumet där ansvaret är odelat: en enda ägare som är svarsskyldig inför verksamheten för det som levereras, och som inte kan peka över gapet. Ansvar som är delat över gränsen är ansvar som har försvunnit, och att återföra det till en enda punkt på hemmaplan är mycket av det som gör modellen styrbar.

5. Att dra linjen

Om kommandot stannar på hemmaplan och utförandet går offshore, hänger allt på var linjen mellan dem dras, uppgift för uppgift. Den modell som styr valet har två axlar. Den första är en uppgifts kontextbelastning: hur mycket lokal, tyst, verksamhetsspecifik kunskap som krävs för att lösa den korrekt, hög för en ändring som berör en subtil regulatorisk regel eller ett långvarigt kundåtagande, låg för en väl avgränsad komponent med ett tydligt kontrakt. Den andra är den specifikationsfullständighet kommandocentrumet kan ge den: hur fullständigt dess tvetydigheter kan lösas i förväg, på papper, utan ett samtal. En uppgift är säker att offshora när den residuala tvetydighet som når offshore-podden, dess kontextbelastning netto efter den specifikationsfullständighet som tillämpas på den, är liten. Om vi skriver $\kappa$ för kontextbelastning och $s$ för specifikationsfullständighet, båda på en gemensam skala, är residualen

och det är $\alpha$, inte arbetets råa svårighetsgrad, som förutsäger omarbete. Modellen har en skarp ledningsmässig läsning, ritad i tabell 1. En uppgift med låg kontext offshoras rent oavsett dess tekniska svårighetsgrad. En uppgift med hög kontext är inte olämplig för offshoring; den är olämplig för offshoring ospecificerad, och kommandocentrumets jobb är att höja $s$ tills $\alpha$ är tillräckligt litet för att skickas. Där kontextbelastningen är genuint oreducerbar, där kunskapen inte alls kan skrivas ner, stannar uppgiften på hemmaplan, och att erkänna det ärligt är en del av disciplinen. Det felläge modellen namnger är uppgiften med hög kontext som skickas med en specifikation av låg fullständighet: maximal residual tvetydighet, löst offshore genom gissning, på maximalt avstånd.

6. Klockan

Tidsskillnaden mellan en västerländsk verksamhet och Indien, omkring nio till tolv timmar, är den egenskap praktiker oftast behandlar som en ren belastning och den som kommandocentrumet renast kan omvandla till en tillgång. Lämnad obevakad är gapet latens: en fråga ställd vid slutet av offshore-dagen besvaras vid slutet av dagen på hemmaplan, och ett enda förtydligande kostar en kalenderdag oavsett dess innehåll, så en kedja av förtydliganden kostar en vecka för att lösa en timmes verkligt innehåll. Detta är mekanismen genom vilken illa skött offshoring känns långsam även när alla arbetar hårt: den kritiska vägen löper genom gapet, och gapet lägger till en dag per korsning.

Väl skött är samma gap ett andra skift. Om kommandocentrumet lämnar över arbete vars tvetydigheter redan är lösta, utför offshore-poddarna under natten på hemmaplan och returnerar resultat till morgonen på hemmaplan, och den dag verksamheten sover sig igenom är en dag av framsteg snarare än en dag av väntan. Skillnaden mellan de två utfallen är helt och hållet den residuala tvetydigheten $\alpha$ i det som lämnas över: en överlämning med $\alpha \approx 0$ behöver ingen tur och retur och klockan är ren vinst; en överlämning full av olösta frågor vänder klockan mot dig, eftersom varje fråga är en hel dag. Ett grovt sätt att se det är att den effektiva uppsnabbningen från det andra skiftet är

där $\eta$ mäter hur rent arbete kan lämnas över och $\alpha$ är den residuala tvetydigheten i ekvation (1); när $\alpha\to 0$ närmar sig klockan ett genuint extra skift, och när $\alpha$ stiger kollapsar vinsten och vänds sedan till dag-per-fråga-skatten. Kommandocentrumet förtjänar klockan genom att äga den specifikation och den definition av klart som gör $\alpha$ litet, vilket är varför follow-the-sun är en konsekvens av gott kommando, inte ett schemaläggningstrick som kan köpas separat.

7. Kommandoförhållandet

Hur mycket kommando är tillräckligt? Frågan har ett verkligt svar, och det är varken ”så lite som möjligt”, den instinkt som frambringar kasta-över-muren-offshoring, eller ”så mycket som möjligt”, vilket återuppbygger på hemmaplan den kostnad som offshoring var tänkt att göra sig av med. Låt $r$ vara kommandoförhållandet, kapaciteten hos kommandocentrumet på hemmaplan som en andel av den leveranskapacitet offshore det styr. Kommando kostar den höga hemmaplanstaxan $w_c$ per enhet; leverans kostar den låga offshore-taxan $w_o$ per enhet. Värdet av kommando är att det sänker den residuala tvetydighet som når poddarna och därmed det omarbete de måste göra: mer kommando betyder mer arbete specificerat, granskat och grindat före och efter att det korsar gapet, och därmed en lägre omarbetsmultiplikator på det levererade arbetet. En användbar form för den multiplikatorn är

där $a$ skalar det omarbete som inget kommando alls skulle medföra, satt av arbetets inneboende tvetydighet, och $b$ mäter hur effektivt kommando omvandlas till löst tvetydighet. Den totala kostnaden för att leverera en enhet färdigt arbete, kommando plus omarbetad leverans, är då

en summa av en stigande term, kostnaden för kommando, och en fallande, det omarbete som kommando förhindrar, så den har ett enda inre minimum. Att sätta $C'(r)=0$ ger det kostnadsminimerande kommandoförhållandet

vilket är dokumentets centrala kvantitativa resultat. Det säger tre saker en chef kan handla på. Den optimala mängden kommando är positiv: $r^\ast > 0$ närhelst $w_o a b > w_c$, det vill säga närhelst kommando är det minsta effektivt och tvetydighet det minsta verklig, så att kasta arbete över muren ($r = 0$) är aldrig optimalt. Den är ändlig: kommando bortom $r^\ast$ kostar mer än det omarbete det sparar, så att behålla allt på hemmaplan är inte optimalt heller. Och det rör sig åt rätt håll: $r^\ast$ stiger med arbetets tvetydighet ($a$) och med hur väl kommando löser den ($b$), och faller när kommando på hemmaplan blir dyrt i förhållande till leverans offshore ($w_c/w_o$), så tvetydiga portföljer med hög kontext motiverar ett tjockare kommandoskikt och enkla, väl avgränsade ett tunnare. Figur 2 ritar $C(r)$ och de två felregimerna på ömse sidor om optimumet.

8. Ett konstruerat fall

Fallet är konstruerat, inte observerat: dess siffror är illustrativa och internt konsistenta, och det är avsett att visa modellens storheter anta rimliga värden snarare än att rapportera ett resultat. En västerländsk koncern driver applikationsutveckling för sina back office-system och offshorade, för tre år sedan, huvuddelen av den till en leverantör i Indien på basis av bemanningsförstärkning: den behöll en handfull projektledare på hemmaplan, skrev krav i den form den alltid hade gjort, och mätte framgång i flyttad personalstyrka och sparad dagtaxa. På pappret hade den halverat kostnaden för en utvecklare. I praktiken hade genomströmningsleveransen av en funktion, från begäran till accepterad produktionsändring, förlängts, defektläckaget till produktion hade stigit, och en stor och växande andel av offshore-teamets timmar gick till att omarbeta funktioner som hade byggts enligt en rimlig men felaktig tolkning av ett tvetydigt krav. Besparingen var brutto; netto var den tunn och fallande. Tabell 2 ger före-kolumnen.

Koncernen byggde sedan om uppdraget kring ett kommandocentrum. Den bytte inte leverantör eller flyttade hem arbete; den lade till ett tunt, seniort skikt på hemmaplan, några procent av den totala personalstyrkan, som tog ägarskap över de fem tingen i sektion 4: den skrev om krav som specifikationer med explicita acceptanskriterier, skar om arkitekturen så att varje offshore-pod ägde en modul bakom ett definierat gränssnitt, höll en enda ordnad backlog, och körde en acceptansgrind innan något nådde produktion. Offshore-teamet och dess taxor var oförändrade; det som ändrades var den residuala tvetydigheten $\alpha$ som nådde det. Omarbetet föll när specifikationer löste den gissning som hade drivit det, defektläckaget sjönk när grinden fångade det som gapet brukade dölja, och klockan vändes från latens till ett andra skift när överlämningar slutade behöva turer och returer. Kostnaden för det tillagda kommandot var en bråkdel av det omarbete det avlägsnade, vilket är ekvation (5) i praktiken: uppdraget hade kört långt till vänster om $r^\ast$, och att röra sig mot det sänkte den totala kostnaden även om det höjde kostnaden på hemmaplan. Tabell 2 spårar förändringen.

9. Vad som ändras för driftsmodellen

Att anamma kommandocentrumet ändrar vad ett företag måste vara bra på, och ändringen är obekväm eftersom den går emot den instinkt som motiverade offshoring. Besparingen är fortfarande verklig, men den fångas endast genom att spendera, på hemmaplan och till seniora taxor, på det kommandoskikt som den naiva affärskalkylen behandlade som slöseri att eliminera. Tabell 3 lägger fram den arbetsdelning modellen kräver. Den knappa resursen blir den handfull seniora människor som kan hålla avsikt, arkitektur och acceptans väl, och ett företags offshoringskapacitet begränsas av hur många sådana människor det har, inte av hur många offshore-ingenjörer det kan anställa. Måttet ändras också: flyttad personalstyrka och sparad dagtaxa, de siffror som får kasta-över-muren-offshoring att se bra ut, ersätts av ledtid för funktion, defektläckage och andelen offshore-timmar som läggs på omarbete, de siffror som avslöjar om kommandot gör sitt jobb.

Det finns en andra förskjutning, i var senioriteten sitter. Kasta-över-muren-offshoring tenderar att skicka det intressanta, seniora arbetet offshore tillsammans med resten och behålla ett juniort koordineringsskikt hemma; kommandocentrummodellen inverterar det, och behåller senioriteten på hemmaplan där kontexten är och låter offshore-teamet vara utmärkt på utförande utan att ombes leverera kontext det inte kan ha. Detta misstolkas ofta som misstro mot offshore-teamet. Det är tvärtom: det är det arrangemang som låter ett kompetent offshore-team göra sitt bästa arbete, genom att inte be det lösa tvetydigheter som ingen på dess avstånd skulle kunna lösa väl, och genom att ge det specifikationer tillräckligt tydliga för att dess kompetens läggs på att bygga snarare än på att gissa.

10. Invändningar och svar

Kommandocentrumet lägger bara till kostnad på hemmaplan och urholkar besparingen. Det lägger till kostnad på hemmaplan och höjer nettobesparingen, vilket är hela poängen med ekvation (5): de flesta misslyckade uppdrag sitter långt till vänster om $r^\ast$, där lite mer kommando avlägsnar mycket mer omarbete än det kostar. Kommandocentrumet är inte omkostnad ovanpå besparingen; det är den mekanism som omvandlar en bruttobesparing till en netto. Ett företag som genuint redan är vid $r^\ast$ bör inte lägga till kommando; nästan inga är det.

Om du måste specificera allt så precist, varför inte bara bygga det på hemmaplan? Därför att specifikation och konstruktion har mycket olika kostnader och mycket olika knapphet. Specifikation är en liten kvantitet seniort, kontextbundet arbete; konstruktion är en stor kvantitet arbete som inte är kontextbundet när det väl är specificerat. Modellen skickar den stora, billig-att-placera kvantiteten dit den är prisvärd och behåller endast den lilla, kontextbundna kvantiteten hemma. Att slå samman de två igen avstår från precis det arbitrage som är verkligt.

Moderna verktyg och videosamtal har gjort avstånd irrelevant. De har gjort det mindre, inte irrelevant, och bevisen för att avstånd fortfarande spelar roll är robusta (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Verktyg sänker kostnaden för en korsning; de avlägsnar inte den dag klockan lägger till en tur och retur, och återställer inte den informella, omgivande kommunikation som samlokaliserade team använder för att lösa tvetydighet utan att märka det. Kommandocentrumet är det strukturella svar som verktyg kompletterar men inte ersätter.

Vår offshore-partner är mycket kompetent och kan äga hela saken. Kompetens är inte frågan; kontext är. Ett högst kompetent offshore-team kan fortfarande inte lösa en tvetydighet vars lösning kräver att man vet vad verksamheten menade, och att be det göra så ställer dess kompetens mot ett problem som avståndet gör olösligt. Modellen behåller ansvaret på hemmaplan inte för att offshore-teamet är svagt utan för att ansvaret är bundet till en kontext som är på hemmaplan.

11. Begränsningar

Detta är ett resonemang riktat till praktiker med en avsiktligt enkel modell, och dess gränser bör vara tydliga. Modellen i sektionerna 5 till 7 är illustrativ: den residuala tvetydighetens form i ekvation (1), den exponentiella omarbetsmultiplikatorn i ekvation (3) och det enda optimala förhållandet i ekvation (5) är förenklingar valda för läsbarhet, och konstanterna $a$, $b$, $w_c$ och $w_o$ är inte uppmätta här; ett företag kan uppskatta dem från sina egna omarbets- och taxedata, och vi skulle förvänta oss att den kvalitativa formen, ett inre optimum som rör sig med tvetydighet och relativ kostnad, överlever även där den exakta formen inte gör det. Resonemanget är avgränsat till arbete vars tvetydigheter, med ansträngning, kan lösas till specifikation; genuint forskningslikt arbete, där ingen ännu vet vad korrekt är, passar modellen illa och bör mestadels förbli samlokaliserat. Dokumentet drar på Indien eftersom det är där djupet i tillgången och skalan i praktiken finns, men inget i modellen är specifikt för ett land; det gäller varje uppdelning mellan hemmaplan och offshore över ett verkligt avstånd och en verklig klocka. Och modellen förutsätter ett företag som över huvud taget kan bemanna ett seniort kommandoskikt; ett företag som inte kan bör vara ärligt om att det ännu inte förmår offshora väl, snarare än att offshora illa och kalla resultatet ett utslag om Indien.

12. Slutsats

Att offshora IT-arbete till Indien gör företag besvikna som offshorar fel sak: de skickar ut ansvaret tillsammans med utförandet, slits loss arbetet från den kontext och det omdöme som gör det korrekt, och ser sedan omarbetet och klockan äta upp den besparing de kom för. Reparationen är inte att ta hem arbetet utan att dela det korrekt, och behålla på hemmaplan det tunna, seniora kommando som måste stanna intill verksamheten, bestämma vad som ska byggas, äga arkitekturen och gränssnitten, förvandla avsikt till specifikation, och hålla acceptans, medan utförandet skalar i Indien där talangen är riklig och prisvärd. Var linjen ska dras är en fråga som en uppgifts residuala tvetydighet besvarar, och kommandocentrumets hantverk är att höja specifikationen tills den tvetydigheten är tillräckligt liten för att korsa gapet; hur mycket kommando som ska behållas är en fråga med ett verkligt optimum, positivt och ändligt, som stiger med arbetets tvetydighet och faller när kommando blir dyrt. Gjort på detta sätt upphör avståndet att vara en skatt och tolv timmars-klockan blir ett andra skift, och det arbitrage som alltid var verkligt behålls slutligen. Offshora byggandet; styr det hemifrån. Ett företag som minns vilken av de två som är bunden till kontext, och vilken som inte är det, kan bemästra offshoring till Indien; ett företag som glömmer kommer att fortsätta dra slutsatsen, felaktigt, att problemet var den andra änden av linjen.

Bilaga A. Att upprätta ett kommandocentrum

Metoderna nedan är vad som får delningen i sektion 4 att hålla i praktiken. Ingen är ny; disciplinen är värdet.

Referenser

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.