1. Indledning

I to årtier har tilbuddet været det samme, og regnestykket har set uimodståeligt ud. En ingeniør i Indien koster en brøkdel af en i Vesteuropa eller USA, udbuddet af dem er stort og veluddannet, og engelsk er arbejdssproget, så en virksomhed, der flytter sit softwarearbejde dertil, bør på papiret kunne udføre det samme arbejde for langt mindre. En stor mængde arbejde er flyttet netop på det ræsonnement, og Indien har bygget en IT-serviceindustri i verdensklasse på det. Og alligevel er resultaterne, virksomhed for virksomhed, påfaldende ujævne: nogle organisationer får fremragende software fra Indien i årevis, mens andre får en stigende regning, en faldende leverancekvalitet og en strøm af fejl, som de sparede lønninger aldrig helt dækker, indtil de erklærer offshoring for en fiasko og henter arbejdet hjem, ofte for at konkludere, at problemet var Indien. Det var ikke Indien.

Problemet er, at virksomheder offshorer det forkerte. Intuitionen bag offshoring er, at softwareudvikling er eksekvering, en mængde arbejde, der kan måles i persontimer og købes dér, hvor persontimer er billigst, og ud fra den intuition afleverer en virksomhed en specifikation og en bemanding og venter på output. Men softwareudvikling er ikke primært eksekvering; det er afklaringen af tusind små tvetydigheder, som hver især kræver viden om, hvad forretningen faktisk mente, hvordan denne del skal passe ind i helheden, og hvad “færdigt” egentlig betyder her, og den viden bor dér, hvor forretningen er, ikke dér, hvor tastaturerne er. Når en virksomhed offshorer eksekveringen, offshorer den uforvarende også de beslutninger, til de mennesker, der er længst fra den kontekst, der skal til for at træffe dem godt, og resultatet er arbejde, der er lokalt plausibelt og globalt forkert, opdaget sent, hen over en kløft på tolv timer, og rettet langsomt. Arbejdsarbitragen er reel; den koordinering og det omarbejde, den udløser, er, når det håndteres dårligt, større.

Denne artikel handler om den driftsmodel, der retter fejlen ved ikke at begå den, og modellen har et navn, vi vil bruge hele vejen igennem: onshore kommandocentret. Idéen er at adskille, bevidst og strukturelt, de to ting, som en naiv offshoring blander sammen. Den ene er eksekvering, selve byggeriet, der i sandhed kan og bør skalere dér, hvor talentet er rigeligt og til at betale, i Indien. Den anden er kommando: at beslutte hvad der skal bygges og i hvilken rækkefølge, at eje arkitekturen og grænsefladerne mellem delene, at omsætte det, forretningen vagt ønsker, til en specifikation, der er præcis nok til at blive bygget langt væk uden en samtale, og at bedømme, om det, der kom tilbage, er rigtigt. Kommando er lille, erfaren og dyr, og den bliver onshore, ved siden af den forretning, hvis hensigt den findes for at bære. Tesen er, at en offshoring-indsats’ succes næsten udelukkende afgøres af, om dette kommandolag findes og er godt, og næsten slet ikke af offshore-teamets rå kunnen, som sædvanligvis er fin; og at virksomheder fejler ved at underinvestere i kommando netop fordi kommando er den dyre, onshore del, som offshoring skulle have elimineret.

Bidraget er et argument og en lille model, ikke et benchmark. Afsnit 2 holder påstanden op mod erfaringerne fra offshoring og global softwareudvikling. Afsnit 3 diagnosticerer den egentlige fejl, at offshore ansvaret frem for blot eksekveringen. Afsnit 4 beskriver kommandocentret og hvad det ejer. Afsnit 5 giver en model for, hvor grænsen mellem kommando og levering bør trækkes, afhængigt af kontekstbelastning og specifikationsfuldstændighed. Afsnit 6 behandler uret, og hvordan follow-the-sun bliver en løftestang frem for latenstid. Afsnit 7 udleder det optimale kommandoforhold. Afsnit 8 følger et konstrueret casestudie; afsnit 9 til 12 drager konsekvenserne, besvarer indvendinger, angiver begrænsninger og konkluderer. Spørgsmålet hele vejen igennem er: hvad skal en virksomhed beholde hjemme, og hvor meget af det, for at det arbejde, den sender til Indien, kommer rigtigt tilbage?

2. Baggrund

2.1 Erfaringerne med offshoring

Outsourcing og offshoring af IT har en af de større empiriske litteraturer inden for informationssystemer, og dens dom er ikke, at offshoring ikke betaler sig, men at dens udbytte afhænger af, hvordan det ledes. Lacity, Khan og Willcocks (2009) gennemgår to årtiers studier og finder, at kunde- og leverandørkapabiliteter, kontraktdesign og relationsledelse, snarere end lønforskelle alene, forklarer spredningen mellem vellykkede og mislykkede engagementer. Carmel og Tjia (2005) gav praktikerens beretning om sourcing til en global arbejdsstyrke og katalogiserede de måder, afstand udhuler arbitragen på; Sahay, Nicholson og Krishna (2003) gav den bogtykke beretning om softwareudvikling hen over Indien-grænsen, og Oshri, Kotlarsky og Willcocks (2007) sporede, hvordan en førende indisk leverandør organiserede en global leveringsmodel omkring spredt ekspertise. Rottman og Lacity (2006) destillerede dokumenterede praksisser og fandt, at de virksomheder, der lykkedes, investerede kraftigt i det onshore arbejde med at specificere, koordinere og styre, netop det arbejde, denne artikel kalder kommando. Det gennemgående fund er, at besparelsen er brutto, ikke netto, og at det, der står mellem de to, er ledelsesindsats, der i vid udstrækning bliver hjemme.

2.2 Hvorfor afstand er dyrt

En anden litteratur, om globalt distribueret softwareudvikling, forklarer mekanismen. Herbsleb og Mockus (2003) viste i det studie, der er mest centralt for denne artikel, empirisk, at arbejdsopgaver, der krævede folk på flere lokationer, tog væsentligt længere tid at fuldføre end sammenlignelige opgaver på én lokation, og de sporede forsinkelsen til omkostningen og latenstiden ved den kommunikation, som koordinering på tværs af lokationer kræver. Ramasubbu og Balan (2007) studerede projekter spredt mellem Indien og USA og målte den samme straf direkte i projektpræstation. Olson og Olson (2000) gav det generelle resultat under titlen “distance matters”: samlokaliseret arbejde nyder godt af hurtig, rig, uformel kommunikation, som distribueret arbejde mister, og intet værktøj genopretter den fuldt ud. Kraut og Streeter (1995) havde allerede vist, hvor meget af softwareudvikling der er koordinering snarere end kodning, og Brooks (1975) havde længe forinden givet grunden til, at det at tilføje folk til distribueret arbejde kan gøre det langsommere: kommunikationsveje vokser hurtigere end folkene gør. Lektien er ikke, at distribueret udvikling ikke kan fungere, men at hver grænse, et stykke arbejde må krydse, har en pris, og prisen betales i tid og fejl.

2.3 Conways lov og grænsens arkitektur

Den dybeste idé, artiklen læner sig op ad, er Conways (1968): et systems struktur kommer til at spejle kommunikationsstrukturen i den organisation, der bygger det. Dens korollar for offshoring er præcist og underudnyttet. Hvis offshore og onshore er to løst kommunikerende grupper, vil softwaren være renest, når grænsen mellem dem falder langs en ægte arkitektonisk søm, et modul med en defineret grænseflade, og vil være mest plaget dér, hvor en enkelt tæt koblet klump arbejde deles hen over kløften. Herbsleb og Grinter (1999) bekræftede dette direkte og fandt, at distribueret udvikling lykkes, når arkitekturen er modulær nok til, at hver lokation ejer en del, og grænsefladerne mellem delene er eksplicitte, og kæmper, når den ikke er det. Parnas (1972) gav den designdisciplin, informationsskjulning, der gør sådanne moduler mulige. Den praktiske konsekvens, der udvikles i afsnit 4, er, at det at eje arkitekturen ikke er én af kommandocentrets opgaver blandt mange; det er den opgave, der gør alle de andre mulige, fordi den afgør, hvor den dyre grænse falder.

3. Den egentlige fejl: at offshore ansvar

Den karakteristiske offshoring-fejl er ikke langsom tastning; det er arbejde, der er selvsikkert færdiggjort og stille og roligt forkert. Et krav afleveres, som er fuldstændigt i afsenderens hoved og tvetydigt på papiret, fordi afsenderen deler en kontekst med forretningen, som modtageren ikke gør. Offshore-ingeniøren, kompetent og villig, afklarer tvetydigheden på den eneste måde, der er til rådighed fra tolv tidszoner væk: ved at gætte, rimeligt, og bygge. Gættet opdages at være forkert ved accepten, hvis der er en accept, eller i produktionen, hvis der ikke er, og rettelsen krydser kløften to gange, én gang for at forklare og én gang for at verificere, hvor hver krydsning koster en dag tabt til uret. Gang dette med hver tvetydighed i et virkeligt system, og arbitragen er væk, ikke fordi nogen gjorde noget inkompetent, men fordi de beslutninger, der krævede kontekst, blev truffet dér, hvor der ingen var.

Det, der er sket, i denne artikels sprog, er, at virksomheden offshorede ansvaret, da den kun mente at offshore eksekveringen. Ansvaret for et stykke software er den akkumulerede myndighed til at afklare dets tvetydigheder korrekt: at vide, hvad forretningen mente, at afgøre, hvordan delen tjener helheden, at sige, hvad “korrekt” er. Den myndighed er uadskillelig fra kontekst, og kontekst er lokal. Eksekvering, konstruktionen af en ting, når dens tvetydigheder er afklaret, er ikke kontekstbundet og rejser godt. Fejlen er at behandle de to som én pakke og sende dem af sted sammen; reparationen er at dele dem, beholde ansvaret onshore, hvor dets kontekst bor, og kun sende eksekveringen offshore, med dens tvetydigheder allerede afklaret til specifikation. Alt, hvad der følger, er en uddybning af, hvordan man laver den opdeling og hvor.

4. Kommandocentret

Onshore kommandocentret er det organisatoriske hjem for det ansvar, der ikke må rejse. Det er bevidst lille og bevidst erfarent, fordi dets løftestang kommer fra kvaliteten af nogle få beslutninger snarere end mængden af output, og det sidder ved siden af forretningen, ikke ved siden af tastaturerne. Figur 1 tegner modellen, og tabel 3 deler arbejdet. Kommandocentret ejer fem ting, og modellens disciplin er, at det ejer alle fem og forsøger ikke at eje noget andet.

Fra hensigt til specifikation. Kommandocentrets første produkt er ikke software, men specifikation: oversættelsen af det, forretningen vagt ønsker, til en beskrivelse, der er præcis nok til at blive bygget af en, der ikke kan læne sig over og spørge. Dette er det arbejde, der afklarer tvetydighed dér, hvor konteksten er, så ingen behøver at blive afklaret dér, hvor den ikke er, og det er den enkeltaktivitet med størst løftestang i hele modellen, fordi hver tvetydighed, der efterlades i en specifikation, betales senere til den fulde pris af en rundtur hen over kløften.

Arkitektur og grænseflader. Ifølge Conways lov vil softwaren briste langs organisationens kommunikationssømme, så kommandocentret ejer arkitekturen netop for at vælge, hvor de sømme falder: det dekomponerer systemet i moduler med eksplicitte grænseflader, så hver offshore pod ejer en del, den kan bygge med få afhængigheder på tværs af grænsen. At trække grænsen godt er det, der omdanner afstand fra en skat betalt på hver interaktion til en skat betalt kun ved nogle få veldefinerede grænseflader.

Prioritering. Hvad der bygges først, er en forretningsmæssig vurdering, ikke en leveringsmæssig, og den bliver hos kommandocentret, der holder den enkelte backlog og dens rækkefølge. At sprede prioriteringen ud til offshore-teamet, eller til flere interessenter på én gang, genindfører hen over kløften netop den koordinering, modellen findes for at inddæmme.

Accept og kvalitetsporten. Kommandocentret afgør, hvad “færdigt” er, og tester det returnerede arbejde op imod det, idet det holder en port, forretningen stoler på. Dette er specifikationens modstykke: efter at have defineret korrekthed på forhånd verificerer det den ved returnering, og fordi det er onshore og tæt på forretningen, kan det bedømme egnethed, ikke blot funktion.

Én ansvarlig ejer. Endelig er kommandocentret dér, hvor ansvaret er udelt: en enkelt ejer, der står til ansvar over for forretningen for det, der leveres, og som ikke kan pege hen over kløften. Ansvar, der er delt hen over grænsen, er ansvar, der er forsvundet, og at genoprette det til ét onshore punkt er en stor del af det, der gør modellen styrbar.

5. At trække grænsen

Hvis kommando bliver onshore og eksekvering går offshore, afhænger alt af, hvor grænsen mellem dem trækkes, opgave for opgave. Den model, der styrer valget, har to akser. Den første er en opgaves kontekstbelastning: hvor meget lokal, tavs, forretningsspecifik viden en korrekt afklaring af den kræver, høj for en ændring, der berører en subtil regulatorisk regel eller en mangeårig kundeforpligtelse, lav for en velafgrænset komponent med en klar kontrakt. Den anden er den specifikationsfuldstændighed, kommandocentret kan give den: hvor fuldt dens tvetydigheder kan afklares på forhånd, på papir, uden en samtale. En opgave er sikker at offshore, når den residuale tvetydighed, der når offshore-podden, dens kontekstbelastning fratrukket den specifikationsfuldstændighed, der anvendes på den, er lille. Hvis vi skriver $\kappa$ for kontekstbelastning og $s$ for specifikationsfuldstændighed, begge på en fælles skala, er residualet

og det er $\alpha$, ikke arbejdets rå sværhedsgrad, der forudsiger omarbejde. Modellen har en skarp ledelsesmæssig læsning, tegnet i tabel 1. En opgave med lav kontekst offshores rent uanset dens tekniske sværhedsgrad. En opgave med høj kontekst er ikke uegnet til offshoring; den er uegnet til offshoring uspecificeret, og kommandocentrets opgave er at hæve $s$, indtil $\alpha$ er lille nok til at sende. Dér, hvor kontekstbelastningen er ægte irreducerbar, hvor viden slet ikke kan skrives ned, bliver opgaven onshore, og at erkende det ærligt er en del af disciplinen. Den fejltilstand, modellen navngiver, er opgaven med høj kontekst sendt af sted med en specifikation med lav fuldstændighed: maksimal residual tvetydighed, afklaret offshore ved gætværk, på maksimal afstand.

6. Uret

Tidsforskellen mellem en vestlig forretning og Indien, cirka ni til tolv timer, er det træk, praktikere oftest behandler som en ren byrde, og det, kommandocentret renest kan omdanne til et aktiv. Uplejet er kløften latenstid: et spørgsmål stillet i slutningen af offshore-dagen besvares i slutningen af onshore-dagen, og en enkelt afklaring koster en kalenderdag uanset dens indhold, så en kæde af afklaringer koster en uge at afklare en time med reelt indhold. Dette er den mekanisme, hvorved dårligt drevet offshoring føles langsom, selv når alle arbejder hårdt: den kritiske vej løber gennem kløften, og kløften lægger en dag til pr. krydsning.

Kørt godt er den samme kløft et andet skift. Hvis kommandocentret overdrager arbejde, hvis tvetydigheder allerede er afklaret, eksekverer offshore-poddene gennem den onshore nat og returnerer resultater ved den onshore morgen, og den dag, forretningen sover igennem, er en dag med fremskridt snarere end en dag med venten. Forskellen mellem de to udfald er fuldstændig den residuale tvetydighed $\alpha$ i det, der overdrages: en overdragelse med $\alpha \approx 0$ kræver ingen rundtur, og uret er ren gevinst; en overdragelse fuld af uafklarede spørgsmål vender uret imod dig, fordi hvert spørgsmål er en hel dag. En grov måde at se det på er, at den effektive hastighedsforøgelse fra det andet skift er

hvor $\eta$ måler, hvor rent arbejde kan overdrages, og $\alpha$ er den residuale tvetydighed fra ligning (1); når $\alpha\to 0$ nærmer uret sig et ægte ekstra skift, og når $\alpha$ stiger, kollapser gevinsten og vender så om til dag-pr-spørgsmål-skatten. Kommandocentret fortjener uret ved at eje den specifikation og den definition af færdigt, der gør $\alpha$ lille, hvilket er grunden til, at follow-the-sun er en konsekvens af god kommando, ikke et planlægningstrick, der kan købes separat.

7. Kommandoforholdet

Hvor meget kommando er nok? Spørgsmålet har et reelt svar, og det er hverken “så lidt som muligt”, det instinkt der frembringer kast-det-over-muren-offshoring, eller “så meget som muligt”, der onshore genopbygger den omkostning, offshoring skulle skille sig af med. Lad $r$ være kommandoforholdet, det onshore kommandocenters kapacitet som en brøkdel af den offshore leveringskapacitet, det styrer. Kommando koster den høje onshore sats $w_c$ pr. enhed; levering koster den lave offshore sats $w_o$ pr. enhed. Værdien af kommando er, at den sænker den residuale tvetydighed, der når poddene, og dermed det omarbejde, de må udføre: mere kommando betyder mere arbejde specificeret, gennemgået og kontrolleret før og efter det krydser kløften, og dermed en lavere omarbejdningsmultiplikator på det leverede arbejde. En brugbar form for den multiplikator er

hvor $a$ skalerer det omarbejde, som slet ingen kommando ville medføre, bestemt af arbejdets iboende tvetydighed, og $b$ måler, hvor effektivt kommando omsættes til afklaret tvetydighed. Den samlede omkostning ved at levere én enhed færdigt arbejde, kommando plus omarbejdet levering, er da

en sum af et stigende led, omkostningen ved kommando, og et faldende, det omarbejde kommando forhindrer, så den har ét enkelt indre minimum. At sætte $C'(r)=0$ giver det omkostningsminimerende kommandoforhold

hvilket er artiklens centrale kvantitative resultat. Det siger tre ting, en leder kan handle på. Den optimale mængde kommando er positiv: $r^\ast > 0$ når som helst $w_o a b > w_c$, det vil sige, når som helst kommando overhovedet er effektiv og tvetydighed overhovedet er reel, så at kaste arbejdet over muren ($r = 0$) er aldrig optimalt. Den er endelig: kommando ud over $r^\ast$ koster mere end det omarbejde, den sparer, så at beholde alt onshore er heller ikke optimalt. Og den bevæger sig den rigtige vej: $r^\ast$ stiger med arbejdets tvetydighed ($a$) og med, hvor godt kommando afklarer den ($b$), og falder, når onshore kommando bliver dyr i forhold til offshore-levering ($w_c/w_o$), så tvetydige porteføljer med høj kontekst berettiger et tykkere kommandolag og simple, velafgrænsede et tyndere. Figur 2 tegner $C(r)$ og de to fejlregimer på hver side af optimum.

8. Et konstrueret casestudie

Casen er konstrueret, ikke observeret: dens tal er illustrative og internt konsistente, og den er ment at vise modellens størrelser antage plausible værdier snarere end at rapportere et resultat. En vestlig koncern driver applikationsudvikling for sine back-office-systemer og offshorede for tre år siden hovedparten af den til en leverandør i Indien på basis af bemandingsforstærkning: den beholdt en håndfuld onshore projektledere, skrev krav i den form, den altid havde, og målte succes på den flyttede bemanding og den sparede dagssats. På papiret havde den halveret omkostningen ved en udvikler. I praksis var den gennemgående levering af en feature, fra anmodning til accepteret produktionsændring, blevet længere, fejludslipsraten til produktion var steget, og en stor og voksende andel af offshore-teamets timer gik til at omarbejde features, der var bygget efter en rimelig, men forkert læsning af et tvetydigt krav. Besparelsen var brutto; netto var den tynd og faldende. Tabel 2 giver før-kolonnen.

Koncernen genopbyggede derefter engagementet omkring et kommandocenter. Den skiftede ikke leverandør og flyttede ikke arbejde hjem; den tilføjede et tyndt, erfarent onshore lag, nogle få procent af den samlede bemanding, der tog ejerskab over de fem ting fra afsnit 4: den omskrev krav til specifikationer med eksplicitte acceptkriterier, skar arkitekturen om, så hver offshore pod ejede et modul bag en defineret grænseflade, holdt en enkelt ordnet backlog og kørte en acceptport, før noget nåede produktion. Offshore-teamet og dets satser var uændrede; det, der ændrede sig, var den residuale tvetydighed $\alpha$, der nåede det. Omarbejdet faldt, efterhånden som specifikationer afklarede det gætværk, der havde drevet det, fejludslipsraten faldt, efterhånden som porten fangede det, kløften plejede at skjule, og uret vendte fra latenstid til et andet skift, efterhånden som overdragelser holdt op med at kræve rundture. Omkostningen ved den tilføjede kommando var en brøkdel af det omarbejde, den fjernede, hvilket er ligning (5) i praksis: engagementet havde kørt langt til venstre for $r^\ast$, og at bevæge sig mod det sænkede den samlede omkostning, selv mens det hævede den onshore omkostning. Tabel 2 følger ændringen.

9. Hvad der ændrer sig for driftsmodellen

At indføre kommandocentret ændrer, hvad en virksomhed må være god til, og ændringen er ubehagelig, fordi den går imod det instinkt, der motiverede offshoring. Besparelsen er stadig reel, men den indhøstes kun ved at bruge penge, onshore og til seniorsatser, på det kommandolag, som den naive forretningscase behandlede som spild, der skulle elimineres. Tabel 3 opstiller den arbejdsdeling, modellen kræver. Den knappe ressource bliver den håndfuld erfarne folk, der kan holde hensigt, arkitektur og accept godt, og en virksomheds offshoring-kapacitet er begrænset af, hvor mange sådanne folk den har, ikke af hvor mange offshore-ingeniører den kan ansætte. Målepunktet ændrer sig også: flyttet bemanding og sparet dagssats, de tal der får kast-det-over-muren-offshoring til at se godt ud, erstattes af gennemløbstid for feature, fejludslip og andelen af offshore-timer brugt på omarbejde, de tal der afslører, om kommando gør sit arbejde.

Der er et andet skift, i hvor senioriteten sidder. Kast-det-over-muren-offshoring har en tendens til at sende det interessante, erfarne arbejde offshore sammen med resten og beholde et juniort koordineringslag hjemme; kommandocenter-modellen vender det om, holder senioriteten onshore, hvor konteksten er, og lader offshore-teamet være fremragende til eksekvering uden at blive bedt om at levere kontekst, det ikke kan have. Dette misforstås ofte som mistillid til offshore-teamet. Det er det modsatte: det er den indretning, der lader et dygtigt offshore-team udføre sit bedste arbejde, ved ikke at bede det afklare tvetydigheder, som ingen på dets afstand kunne afklare godt, og ved at give det specifikationer, der er klare nok til, at dets kompetence bruges på at bygge snarere end på at gætte.

10. Indvendinger og svar

Kommandocentret tilføjer bare onshore omkostning og udhuler besparelsen. Det tilføjer onshore omkostning og hæver nettobesparelsen, hvilket er hele pointen i ligning (5): de fleste fejlende engagementer sidder langt til venstre for $r^\ast$, hvor lidt mere kommando fjerner langt mere omarbejde, end det koster. Kommandocentret er ikke en overhead på besparelsen; det er den mekanisme, der omdanner en bruttobesparelse til en nettobesparelse. En virksomhed, der ægte allerede er ved $r^\ast$, bør ikke tilføje kommando; næsten ingen er det.

Hvis man skal specificere alt så præcist, hvorfor så ikke bare bygge det onshore? Fordi specifikation og konstruktion har meget forskellige omkostninger og meget forskellige knapheder. Specifikation er en lille mængde erfarent, kontekstbundet arbejde; konstruktion er en stor mængde arbejde, der ikke er kontekstbundet, når det først er specificeret. Modellen sender den store, billigt-at-placere mængde til, hvor den er til at betale, og beholder kun den lille, kontekstbundne mængde hjemme. At klappe de to sammen igen opgiver netop den arbitrage, der er reel.

Moderne værktøjer og videoopkald har gjort afstand irrelevant. De har gjort den mindre, ikke irrelevant, og beviset for, at afstand stadig betyder noget, er robust (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Værktøjer sænker omkostningen ved en krydsning; de fjerner ikke den dag, uret lægger til en rundtur, og genopretter heller ikke den uformelle, omgivende kommunikation, som samlokaliserede teams bruger til at afklare tvetydighed uden at bemærke det. Kommandocentret er det strukturelle svar, som værktøjer supplerer, men ikke erstatter.

Vores offshore-partner er meget dygtig og kan eje det hele. Kunnen er ikke problemet; kontekst er. Et højt kompetent offshore-team kan stadig ikke afklare en tvetydighed, hvis afklaring kræver viden om, hvad forretningen mente, og at bede det om at gøre det stiller dets kompetence op mod et problem, afstanden gør uløseligt. Modellen holder ansvaret onshore ikke fordi offshore-teamet er svagt, men fordi ansvar er bundet til en kontekst, der er onshore.

11. Begrænsninger

Dette er et praktikerrettet argument med en bevidst enkel model, og dens grænser bør være tydelige. Modellen i afsnit 5 til 7 er illustrativ: residualtvetydighedsformen i ligning (1), den eksponentielle omarbejdningsmultiplikator i ligning (3) og det enkelte optimale forhold i ligning (5) er forenklinger valgt af hensyn til læseligheden, og konstanterne $a$, $b$, $w_c$ og $w_o$ er ikke målt her; en virksomhed kan estimere dem ud fra sine egne omarbejds- og satsdata, og vi ville forvente, at den kvalitative form, et indre optimum der bevæger sig med tvetydighed og relativ omkostning, overlever selv dér, hvor den eksakte form ikke gør. Argumentet er afgrænset til arbejde, hvis tvetydigheder med indsats kan afklares til specifikation; ægte forskningslignende arbejde, hvor ingen endnu ved, hvad korrekt er, passer dårligt til modellen og bør for det meste forblive samlokaliseret. Artiklen trækker på Indien, fordi det er dér, dybden i udbuddet og skalaen i praksissen er, men intet i modellen er specifikt for et land; den gælder enhver onshore–offshore-opdeling hen over en virkelig afstand og et virkeligt ur. Og modellen forudsætter en virksomhed, der overhovedet er i stand til at bemande et senior kommandolag; en virksomhed, der ikke kan, bør være ærlig om, at den endnu ikke er i stand til at offshore godt, snarere end at offshore dårligt og kalde resultatet en dom over Indien.

12. Konklusion

At offshore IT-arbejde til Indien skuffer de virksomheder, der offshorer det forkerte: de sender ansvaret ud sammen med eksekveringen og river dermed arbejdet løs fra den kontekst og dømmekraft, der gør det korrekt, og ser så omarbejde og uret æde den besparelse, de kom efter. Reparationen er ikke at hente arbejdet hjem, men at dele det korrekt, at holde onshore den tynde, erfarne kommando, der må blive ved siden af forretningen, at beslutte hvad der skal bygges, at eje arkitekturen og grænsefladerne, at omsætte hensigt til specifikation og at holde accepten, mens eksekveringen skalerer i Indien, hvor talentet er rigeligt og til at betale. Hvor grænsen skal trækkes er et spørgsmål, som en opgaves residuale tvetydighed besvarer, og kommandocentrets håndværk er at hæve specifikationen, indtil den tvetydighed er lille nok til at krydse kløften; hvor meget kommando der skal beholdes er et spørgsmål med et reelt optimum, positivt og endeligt, der stiger med arbejdets tvetydighed og falder, når kommando bliver dyr. Gjort på denne måde holder afstanden op med at være en skat, og det tolv-timers ur bliver et andet skift, og den arbitrage, der altid var reel, bliver endelig beholdt. Offshore byggeriet; kommandér det hjemmefra. En virksomhed, der husker, hvilken af de to der er bundet til kontekst, og hvilken der ikke er, kan mestre offshoring til Indien; en virksomhed, der glemmer det, vil blive ved med at konkludere, fejlagtigt, at problemet var den anden ende af linjen.

Appendiks A. At opstille et kommandocenter

Praksisserne nedenfor er det, der får opdelingen fra afsnit 4 til at holde i praksis. Ingen er ny; disciplinen er værdien.

Referencer

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.