1. Johdanto

Kahden vuosikymmenen ajan tarjous on ollut sama ja laskelma on näyttänyt vastustamattomalta. Insinööri Intiassa maksaa murto-osan siitä, mitä Länsi-Euroopassa tai Yhdysvalloissa, heitä on tarjolla paljon ja hyvin koulutettuina, ja englanti on työkieli, joten yrityksen, joka siirtää ohjelmistotyönsä sinne, pitäisi paperilla tehdä sama työ paljon halvemmalla. Suuri määrä työtä on siirtynyt juuri tällä päättelyllä, ja Intia on rakentanut sen varaan maailmanluokan IT-palvelualan. Ja silti tulokset ovat yritys yritykseltä hämmästyttävän epätasaisia: jotkin organisaatiot saavat Intiasta erinomaisia ohjelmistoja vuosikausia, kun taas toiset saavat kasvavan laskun, laskevan toimituksen laadun ja sellaisen virheiden virran, jota säästetyt palkat eivät koskaan aivan kata, kunnes ne julistavat ulkoistamisen epäonnistuneeksi ja tuovat työn kotiin, usein päätyen siihen johtopäätökseen, että ongelma oli Intia. Se ei ollut Intia.

Ongelma on, että yritykset ulkoistavat väärän asian. Ulkoistamisen taustalla oleva intuitio on, että ohjelmistokehitys on toteutusta, työmäärä, joka voidaan mitata henkilötyötunteina ja ostaa sieltä, missä henkilötyötunnit ovat halvimpia, ja tämän intuition varassa yritys luovuttaa määrittelyn ja henkilöstömäärän ja odottaa tuotosta. Mutta ohjelmistokehitys ei ole pääasiassa toteutusta; se on tuhannen pienen moniselitteisyyden ratkaisemista, joista jokainen edellyttää tietoa siitä, mitä liiketoiminta oikeastaan tarkoitti, miten tämän osan on määrä sopia kokonaisuuteen ja mitä ”valmis” täällä todella tarkoittaa, ja tuo tieto asuu siellä, missä liiketoiminta on, eikä siellä, missä näppäimistöt ovat. Kun yritys ulkoistaa toteutuksen, se tietämättään ulkoistaa myös nuo päätökset ihmisille, jotka ovat kauimpana siitä kontekstista, jota niiden tekeminen hyvin edellyttää, ja tuloksena on työtä, joka on paikallisesti uskottavaa mutta globaalisti väärää, havaitaan myöhään, kahdentoista tunnin kuilun yli, ja korjataan hitaasti. Työvoima-arbitraasi on todellinen; sen laukaisema koordinointi ja uudelleentyö ovat huonosti hoidettuina suurempia.

Tämä artikkeli käsittelee toimintamallia, joka korjaa virheen jättämällä sen tekemättä, ja mallilla on nimi, jota käytämme läpi tekstin: kotimainen komentokeskus. Ajatuksena on erottaa tarkoituksellisesti ja rakenteellisesti ne kaksi asiaa, jotka naiivi ulkoistaminen sulauttaa yhteen. Toinen on toteutus, rakentaminen, joka aidosti voi ja sen pitää skaalautua sinne, missä osaamista on runsaasti ja edullisesti, Intiaan. Toinen on komento: sen päättäminen, mitä rakennetaan ja missä järjestyksessä, arkkitehtuurin ja osien välisten rajapintojen omistaminen, sen muuntaminen, mitä liiketoiminta epämääräisesti haluaa, määrittelyksi, joka on tarkka riittävän kaukana rakennettavaksi ilman keskustelua, ja sen arvioiminen, onko palautunut työ oikeaa. Komento on pientä, kokenutta ja kallista, ja se pysyy kotimaassa, sen liiketoiminnan vieressä, jonka tarkoitusta kantaakseen se on olemassa. Teesi on, että ulkoistamisohjelman menestys määräytyy lähes kokonaan sen perusteella, onko tämä komentokerros olemassa ja hyvä, ja tuskin lainkaan ulkomaisen tiimin raa’an kyvykkyyden perusteella, joka on yleensä kunnossa; ja että yritykset epäonnistuvat aliresursoimalla komennon juuri siksi, että komento on se kallis, kotimainen osa, jonka ulkoistamisen oli määrä poistaa.

Kontribuutio on argumentti ja pieni malli, ei vertailututkimus. Luku 2 asettaa väitteen ulkoistamisen ja globaalin ohjelmistotuotannon historiaa vasten. Luku 3 diagnosoi todellisen epäonnistumisen, vastuun ulkoistamisen pelkän toteutuksen sijaan. Luku 4 kuvaa komentokeskuksen ja sen, mitä se omistaa. Luku 5 esittää mallin siitä, mihin komennon ja toimituksen välinen raja tulisi vetää, mikä riippuu kontekstikuormasta ja määrittelyn täydellisyydestä. Luku 6 käsittelee kelloa ja sitä, miten follow-the-sun muuttuu vipuvoimaksi viiveen sijaan. Luku 7 johtaa optimaalisen komentosuhteen. Luku 8 seuraa rakennettua tapausta; luvut 9–12 vetävät johtopäätökset, vastaavat vastaväitteisiin, esittävät rajoitukset ja päättävät työn. Läpi tekstin kysymys on: mitä yrityksen on pidettävä kotona, ja kuinka paljon siitä, jotta työ, jonka se lähettää Intiaan, palaa oikeana?

2. Tausta

2.1 Ulkoistamisen historia

IT:n ulkoistamisella ja ulkomaille siirtämisellä on yksi tietojärjestelmätieteen laajemmista empiirisistä kirjallisuuksista, ja sen tuomio ei ole se, ettei ulkoistaminen kannata, vaan että sen tuotto riippuu siitä, miten sitä johdetaan. Lacity, Khan ja Willcocks (2009), tarkastellessaan kahden vuosikymmenen tutkimuksia, havaitsevat, että asiakkaan ja toimittajan kyvykkyydet, sopimussuunnittelu ja suhteen hallinta, eikä pelkät palkkaerot, selittävät onnistuneiden ja epäonnistuneiden toimeksiantojen välisen eron. Carmel ja Tjia (2005) esittivät käytännön kuvauksen hankinnasta globaalilta työvoimalta ja luetteloivat tavat, joilla etäisyys nakertaa arbitraasia; Sahay, Nicholson ja Krishna (2003) esittivät kirjanmittaisen kuvauksen ohjelmistokehityksestä Intian rajan yli, ja Oshri, Kotlarsky ja Willcocks (2007) jäljittivät, miten johtava intialainen toimittaja järjesti globaalin toimitusmallin hajautetun asiantuntemuksen ympärille. Rottman ja Lacity (2006) tiivistivät toteennäytetyt käytännöt ja havaitsivat, että menestyneet yritykset panostivat voimakkaasti kotimaiseen määrittelyn, koordinoinnin ja hallinnan työhön, juuri siihen työhön, jota tämä artikkeli kutsuu komennoksi. Johdonmukainen havainto on, että säästö on brutto eikä netto, ja että näiden kahden välissä seisoo johtamisponnistus, joka suurelta osin pysyy kotona.

2.2 Miksi etäisyys on kallista

Toinen kirjallisuus, joka koskee globaalisti hajautettua ohjelmistokehitystä, selittää mekanismin. Herbsleb ja Mockus (2003) osoittivat tämän artikkelin kannalta keskeisimmässä tutkimuksessa empiirisesti, että työkohteet, jotka edellyttivät ihmisiä useissa toimipisteissä, veivät valmistuakseen huomattavasti kauemmin kuin vastaavat yhden toimipisteen kohteet, ja jäljittivät viiveen sen viestinnän kustannukseen ja viiveeseen, jota toimipisteiden välinen koordinointi edellyttää. Ramasubbu ja Balan (2007), tutkiessaan Intian ja Yhdysvaltojen välille hajautettuja projekteja, mittasivat saman rasitteen suoraan projektin suorituskyvystä. Olson ja Olson (2000) esittivät yleisen tuloksen otsikolla ”etäisyydellä on väliä”: samassa paikassa tehty työ hyötyy nopeasta, rikkaasta, epämuodollisesta viestinnästä, jonka hajautettu työ menettää, eikä mikään työkalu palauta sitä täysin. Kraut ja Streeter (1995) olivat jo osoittaneet, kuinka suuri osa ohjelmistokehityksestä on koordinointia eikä koodausta, ja Brooks (1975) oli jo kauan aiemmin esittänyt syyn siihen, miksi ihmisten lisääminen hajautettuun työhön voi hidastaa sitä: viestintäpolut kasvavat nopeammin kuin ihmiset. Opetus ei ole se, ettei hajautettu kehitys voi toimia, vaan että jokaisella rajalla, jonka työ joutuu ylittämään, on hinta, ja hinta maksetaan ajassa ja virheissä.

2.3 Conwayn laki ja rajan arkkitehtuuri

Syvin ajatus, johon artikkeli nojaa, on Conwayn (1968): järjestelmän rakenne alkaa heijastaa sen rakentavan organisaation viestintärakennetta. Sen seuraus ulkoistamiselle on täsmällinen ja alikäytetty. Jos ulkomainen ja kotimainen ovat kaksi löyhästi viestivää ryhmää, niin ohjelmisto on puhtaimmillaan silloin, kun niiden välinen raja osuu aitoon arkkitehtoniseen saumaan, moduuliin, jolla on määritelty rajapinta, ja ongelmallisimmillaan silloin, kun yksi tiiviisti kytketty työmöykky pilkotaan kuilun yli. Herbsleb ja Grinter (1999) vahvistivat tämän suoraan havaiten, että hajautettu kehitys onnistuu, kun arkkitehtuuri on riittävän modulaarinen, että kukin toimipiste omistaa osan ja osien väliset rajapinnat ovat eksplisiittisiä, ja kamppailee, kun näin ei ole. Parnas (1972) esitti suunnittelun kurinalaisuuden, tiedon kätkemisen, joka tekee tällaiset moduulit mahdollisiksi. Käytännön seuraus, jota kehitellään luvussa 4, on se, että arkkitehtuurin omistaminen ei ole yksi komentokeskuksen monista tehtävistä; se on tehtävä, joka tekee kaikki muut mahdollisiksi, koska se ratkaisee, mihin kallis raja osuu.

3. Todellinen epäonnistuminen: vastuun ulkoistaminen

Ominainen ulkoistamisen epäonnistuminen ei ole hidasta näppäilyä; se on työtä, joka on itsevarmasti saatettu valmiiksi ja hiljaa väärin. Luovutetaan vaatimus, joka on täydellinen lähettäjän päässä ja moniselitteinen paperilla, koska lähettäjä jakaa liiketoiminnan kanssa kontekstin, jota vastaanottaja ei jaa. Ulkomainen insinööri, pätevä ja halukas, ratkaisee moniselitteisyyden ainoalla kahdentoista aikavyöhykkeen päästä käytettävissä olevalla tavalla: arvaamalla, järkevästi, ja rakentamalla. Arvaus havaitaan vääräksi hyväksynnässä, jos hyväksyntää on, tai tuotannossa, jos ei ole, ja korjaus ylittää kuilun kahdesti, kerran selittääkseen ja kerran varmentaakseen, kummankin ylityksen ollessa kellolle menetetty päivä. Kerro tämä jokaisella todellisen järjestelmän moniselitteisyydellä, ja arbitraasi on poissa, ei siksi, että kukaan olisi tehnyt mitään epäpätevää, vaan siksi, että kontekstia vaatineet päätökset tehtiin siellä, missä sitä ei ollut.

Se, mitä on tapahtunut, on tämän artikkelin kielellä se, että yritys ulkoisti vastuun silloin, kun se tarkoitti ulkoistaa vain toteutuksen. Vastuu ohjelmistosta on kertynyt valtuus ratkaista sen moniselitteisyydet oikein: tietää, mitä liiketoiminta tarkoitti, päättää, miten osa palvelee kokonaisuutta, sanoa, mikä on ”oikein”. Tuo valtuus on erottamaton kontekstista, ja konteksti on paikallista. Toteutus, asian rakentaminen sen jälkeen, kun sen moniselitteisyydet on ratkaistu, ei ole kontekstisidonnaista ja matkustaa hyvin. Virhe on käsitellä näitä kahta yhtenä pakettina ja lähettää ne yhdessä; korjaus on erottaa ne, pitää vastuu kotimaassa, missä sen konteksti asuu, ja lähettää ulkomaille vain toteutus, jonka moniselitteisyydet on jo ratkaistu määrittelyksi. Kaikki seuraava on erittelyä siitä, miten tuo jako tehdään ja mihin.

4. Komentokeskus

Kotimainen komentokeskus on sen vastuun organisatorinen koti, joka ei saa matkustaa. Se on tarkoituksellisesti pieni ja tarkoituksellisesti kokenut, koska sen vipuvoima tulee muutaman päätöksen laadusta eikä tuotoksen määrästä, ja se istuu liiketoiminnan vieressä, ei näppäimistöjen vieressä. Kuva 1 piirtää mallin ja taulukko 3 jakaa työn. Komentokeskus omistaa viisi asiaa, ja mallin kurinalaisuus on se, että se omistaa kaikki viisi ja pyrkii olemaan omistamatta mitään muuta.

Tarkoituksesta määrittelyyn. Komentokeskuksen ensimmäinen tuote ei ole ohjelmisto vaan määrittely: sen kääntäminen, mitä liiketoiminta epämääräisesti haluaa, kuvaukseksi, joka on riittävän tarkka sellaisen rakennettavaksi, joka ei voi kurkottaa vieressä olevan puoleen ja kysyä. Tämä on työtä, joka ratkaisee moniselitteisyyden siellä, missä konteksti on, jotta mitään ei tarvitse ratkaista siellä, missä sitä ei ole, ja se on koko mallin yksittäinen eniten vipuvoimaa tuottava toiminta, koska jokaisesta määrittelyyn jätetystä moniselitteisyydestä maksetaan myöhemmin kuilun yli tehdyn edestakaisen matkan täydellä hinnalla.

Arkkitehtuuri ja rajapinnat. Conwayn lain mukaan ohjelmisto murtuu organisaation viestintäsaumoja pitkin, joten komentokeskus omistaa arkkitehtuurin juuri valitakseen, mihin nuo saumat osuvat: se hajottaa järjestelmän moduuleiksi, joilla on eksplisiittiset rajapinnat, niin että kukin ulkomainen podi omistaa osan, jonka se voi rakentaa harvoilla rajat ylittävillä riippuvuuksilla. Rajan hyvin vetäminen on se, mikä muuntaa etäisyyden jokaisesta vuorovaikutuksesta maksetusta verosta veroksi, joka maksetaan vain muutamassa hyvin määritellyssä rajapinnassa.

Priorisointi. Se, mitä rakennetaan ensin, on liiketoiminnallinen arvio, ei toimituksellinen, ja se pysyy komentokeskuksella, joka pitää hallussaan yhden työjonon ja sen järjestyksen. Priorisoinnin hajauttaminen ulkomaiselle tiimille tai usealle sidosryhmälle yhtä aikaa tuo kuilun yli uudelleen juuri sen koordinoinnin, jonka hillitsemiseksi malli on olemassa.

Hyväksyntä ja laatuportti. Komentokeskus päättää, mitä ”valmis” on, ja testaa palautunutta työtä sitä vasten pitäen hallussaan porttia, johon liiketoiminta luottaa. Tämä on määrittelyn vastinpari: määriteltyään oikeellisuuden etukäteen se varmentaa sen palautuessa, ja koska se on kotimaassa ja lähellä liiketoimintaa, se voi arvioida soveltuvuutta eikä pelkkää toimivuutta.

Yksi tilivelvollinen omistaja. Lopuksi komentokeskus on paikka, jossa tilivelvollisuus on jakamaton: yksi omistaja, joka vastaa liiketoiminnalle toimitetusta ja joka ei voi osoittaa kuilun toiselle puolelle. Tilivelvollisuus, joka on jaettu rajan yli, on tilivelvollisuutta, joka on kadonnut, ja sen palauttaminen yhteen kotimaiseen pisteeseen on suuri osa siitä, mikä tekee mallista hallittavan.

5. Rajan vetäminen

Jos komento pysyy kotimaassa ja toteutus menee ulkomaille, kaikki riippuu siitä, mihin niiden välinen raja vedetään, tehtävä tehtävältä. Mallilla, joka ohjaa valintaa, on kaksi akselia. Ensimmäinen on tehtävän kontekstikuorma: kuinka paljon paikallista, hiljaista, liiketoimintakohtaista tietoa sen oikein ratkaiseminen edellyttää, korkea muutokselle, joka koskettaa hienovaraista sääntelysääntöä tai pitkäaikaista asiakassitoumusta, matala hyvin rajatulle komponentille, jolla on selkeä sopimus. Toinen on se määrittelyn täydellisyys, jonka komentokeskus voi sille antaa: kuinka täysin sen moniselitteisyydet voidaan ratkaista ennakolta, paperilla, ilman keskustelua. Tehtävä on turvallista ulkoistaa, kun jäännösepämääräisyys, joka saavuttaa ulkomaisen podin, sen kontekstikuorma vähennettynä siihen sovelletulla määrittelyn täydellisyydellä, on pieni. Merkitsemällä $\kappa$ kontekstikuormaa ja $s$ määrittelyn täydellisyyttä, molemmat yhteisellä asteikolla, jäännös on

ja juuri $\alpha$, eikä työn raaka vaikeus, ennustaa uudelleentyötä. Mallilla on terävä johtamisen tulkinta, joka on piirretty taulukkoon 1. Matalakontekstinen tehtävä ulkoistuu puhtaasti teknisestä vaikeudestaan riippumatta. Korkeakontekstinen tehtävä ei ole ulkoistamiseen soveltumaton; se on soveltumaton ulkoistettavaksi määrittelemättömänä, ja komentokeskuksen tehtävä on nostaa $s$:ää, kunnes $\alpha$ on riittävän pieni lähetettäväksi. Siellä, missä kontekstikuorma on aidosti vähentämätön, missä tietoa ei voida lainkaan kirjoittaa ylös, tehtävä pysyy kotimaassa, ja tämän rehellinen tunnustaminen on osa kurinalaisuutta. Vikatila, jonka malli nimeää, on korkeakontekstinen tehtävä, joka lähetetään matalan täydellisyyden määrittelyllä: suurin jäännösepämääräisyys, joka ratkaistaan ulkomailla arvailemalla, suurimmalla etäisyydellä.

6. Kello

Aikaero länsimaisen liiketoiminnan ja Intian välillä, jostain yhdeksästä kahteentoista tuntiin, on se piirre, jota käytännön toimijat useimmin pitävät pelkkänä rasitteena ja se, jonka komentokeskus voi puhtaimmin muuntaa voimavaraksi. Hoitamattomana kuilu on viivettä: ulkomaisen työpäivän lopussa esitettyyn kysymykseen vastataan kotimaisen työpäivän lopussa, ja yksittäinen täsmennys maksaa kalenteripäivän sisällöstään riippumatta, joten täsmennysten ketju maksaa viikon tunnin verran todellista sisältöä ratkaistakseen. Tämä on se mekanismi, jolla huonosti hoidettu ulkoistaminen tuntuu hitaalta, vaikka kaikki tekisivät kovasti töitä: kriittinen polku kulkee kuilun läpi, ja kuilu lisää päivän kutakin ylitystä kohti.

Hyvin hoidettuna sama kuilu on toinen työvuoro. Jos komentokeskus luovuttaa työtä, jonka moniselitteisyydet on jo ratkaistu, ulkomaiset podit toteuttavat kotimaisen yön läpi ja palauttavat tulokset kotimaiseen aamuun mennessä, ja se päivä, jonka liiketoiminta nukkuu, on edistyksen päivä eikä odottamisen päivä. Ero näiden kahden lopputuloksen välillä on kokonaan luovutettavan työn jäännösepämääräisyys $\alpha$: luovutus, jossa $\alpha \approx 0$, ei tarvitse edestakaista matkaa ja kello on puhdasta hyötyä; luovutus, joka on täynnä ratkaisemattomia kysymyksiä, kääntää kellon sinua vastaan, koska jokainen kysymys on kokonainen päivä. Karkea tapa nähdä se on, että toisen työvuoron tehollinen nopeutus on

missä $\eta$ mittaa, kuinka puhtaasti työ voidaan luovuttaa, ja $\alpha$ on yhtälön (1) jäännösepämääräisyys; kun $\alpha\to 0$, kello lähestyy aitoa ylimääräistä työvuoroa, ja kun $\alpha$ nousee, hyöty romahtaa ja kääntyy sitten päivä-kysymystä-kohden-veroksi. Komentokeskus ansaitsee kellon omistamalla määrittelyn ja valmiin määritelmän, jotka tekevät $\alpha$:sta pienen, minkä vuoksi follow-the-sun on hyvän komennon seuraus eikä aikatauluniksi, joka voidaan ostaa erikseen.

7. Komentosuhde

Kuinka paljon komentoa riittää? Kysymyksellä on todellinen vastaus, eikä se ole ”mahdollisimman vähän”, se vaisto, joka tuottaa aidan yli heittävää ulkoistamista, eikä ”mahdollisimman paljon”, mikä rakentaa kotimaahan uudelleen sen kustannuksen, jonka ulkoistamisen oli määrä karistaa. Olkoon $r$ komentosuhde, kotimaisen komentokeskuksen kapasiteetti osuutena siitä ulkomaisesta toimituskapasiteetista, jota se ohjaa. Komento maksaa korkeaa kotimaista yksikköhintaa $w_c$; toimitus maksaa matalaa ulkomaista yksikköhintaa $w_o$. Komennon arvo on se, että se laskee podeja saavuttavaa jäännösepämääräisyyttä ja siten uudelleentyötä, jota niiden on tehtävä: enemmän komentoa tarkoittaa enemmän työtä määriteltynä, katselmoituna ja portitettuna ennen kuilun ylitystä ja sen jälkeen, ja siten pienempää uudelleentyön kerrointa toimitetulle työlle. Käyttökelpoinen muoto tälle kertoimelle on

missä $a$ skaalaa sen uudelleentyön, jonka olematon komento aiheuttaisi, ja jonka työn luontainen moniselitteisyys asettaa, ja $b$ mittaa, kuinka tehokkaasti komento muuntuu ratkaistuksi moniselitteisyydeksi. Yhden valmiin työyksikön toimittamisen kokonaiskustannus, komento plus uudelleentyöstetty toimitus, on silloin

summa nousevasta termistä, komennon kustannuksesta, ja laskevasta, uudelleentyöstä, jonka komento estää, joten sillä on yksi sisäinen minimi. Asettamalla $C'(r)=0$ saadaan kustannukset minimoiva komentosuhde

joka on artikkelin keskeinen kvantitatiivinen tulos. Se sanoo kolme asiaa, joihin johtaja voi tarttua. Optimaalinen komennon määrä on positiivinen: $r^\ast > 0$ aina kun $w_o a b > w_c$, toisin sanoen aina kun komento on lainkaan tehokasta ja moniselitteisyys lainkaan todellista, joten työn heittäminen aidan yli ($r = 0$) ei ole koskaan optimaalista. Se on äärellinen: komento yli $r^\ast$:n maksaa enemmän kuin uudelleentyö, jonka se säästää, joten kaiken pitäminen kotimaassa ei ole optimaalista sekään. Ja se liikkuu oikeaan suuntaan: $r^\ast$ nousee työn moniselitteisyyden ($a$) ja sen myötä, kuinka hyvin komento sen ratkaisee ($b$), ja laskee, kun kotimainen komento kallistuu suhteessa ulkomaiseen toimitukseen ($w_c/w_o$), joten moniselitteiset, korkeakontekstiset portfoliot oikeuttavat paksumman komentokerroksen ja yksinkertaiset, hyvin rajatut ohuemman. Kuva 2 piirtää $C(r)$:n ja kaksi vikatilaa optimin molemmin puolin.

8. Rakennettu tapaus

Tapaus on rakennettu, ei havaittu: sen luvut ovat havainnollistavia ja sisäisesti johdonmukaisia, ja sen on tarkoitus näyttää mallin suureiden saavan uskottavia arvoja pikemminkin kuin raportoida tulosta. Länsimainen ryhmä hoitaa taustajärjestelmiensä sovelluskehitystä ja ulkoisti kolme vuotta sitten suurimman osan siitä toimittajalle Intiaan staff augmentation -periaatteella: se piti kourallisen kotimaisia projektipäälliköitä, kirjoitti vaatimukset siinä muodossa, jossa se oli aina kirjoittanut, ja mittasi menestystä siirretyllä henkilöstömäärällä ja säästetyllä päivähinnalla. Paperilla se oli puolittanut kehittäjän kustannuksen. Käytännössä ominaisuuden suora läpitoimitus, pyynnöstä hyväksyttyyn tuotantomuutokseen, oli pidentynyt, virheiden karkaamisaste tuotantoon oli noussut, ja suuri ja kasvava osuus ulkomaisen tiimin tunneista meni sellaisten ominaisuuksien uudelleentyöhön, jotka oli rakennettu moniselitteisen vaatimuksen järkevän mutta väärän tulkinnan mukaan. Säästö oli brutto; nettona se oli ohut ja laskeva. Taulukko 2 antaa ”ennen”-sarakkeen.

Ryhmä rakensi sitten toimeksiannon uudelleen komentokeskuksen ympärille. Se ei vaihtanut toimittajaa eikä siirtänyt työtä kotiin; se lisäsi ohuen, kokeneen kotimaisen kerroksen, muutaman prosentin koko henkilöstömäärästä, joka otti omistukseensa luvun 4 viisi asiaa: se kirjoitti vaatimukset uudelleen määrittelyiksi, joilla oli eksplisiittiset hyväksymiskriteerit, leikkasi arkkitehtuurin uudelleen niin, että kukin ulkomainen podi omisti moduulin määritellyn rajapinnan takana, piti hallussaan yhtä järjestettyä työjonoa ja ajoi hyväksyntäportin ennen kuin mikään saavutti tuotannon. Ulkomainen tiimi ja sen hinnat pysyivät muuttumattomina; se, mikä muuttui, oli sitä saavuttava jäännösepämääräisyys $\alpha$. Uudelleentyö väheni, kun määrittelyt ratkaisivat sen ajaneen arvailun, virheiden karkaamisaste laski, kun portti sai kiinni sen, minkä kuilu ennen kätki, ja kello kääntyi viiveestä toiseksi työvuoroksi, kun luovutukset lakkasivat tarvitsemasta edestakaisia matkoja. Lisätyn komennon kustannus oli murto-osa siitä uudelleentyöstä, jonka se poisti, mikä on yhtälö (5) käytännössä: toimeksianto oli toiminut kaukana $r^\ast$:n vasemmalla puolella, ja sitä kohti liikkuminen laski kokonaiskustannusta, vaikka se nostikin kotimaista kustannusta. Taulukko 2 seuraa muutosta.

9. Mikä muuttuu toimintamallissa

Komentokeskuksen omaksuminen muuttaa sitä, missä yrityksen on oltava hyvä, ja muutos on epämukava, koska se käy vastaan sitä vaistoa, joka motivoi ulkoistamista. Säästö on yhä todellinen, mutta se saadaan talteen vain käyttämällä kotimaassa ja kokeneiden hinnoilla rahaa siihen komentokerrokseen, jota naiivi liiketoimintaperustelu piti poistettavana hukkana. Taulukko 3 esittää työnjaon, jota malli edellyttää. Niukasta resurssista tulee se kourallinen kokeneita ihmisiä, jotka osaavat pitää tarkoituksen, arkkitehtuurin ja hyväksynnän hyvin hallussaan, ja yrityksen ulkoistuskapasiteettia rajaa se, kuinka monta tällaista ihmistä sillä on, eikä se, kuinka monta ulkomaista insinööriä se voi palkata. Mittarikin muuttuu: siirretty henkilöstömäärä ja säästetty päivähinta, ne luvut, jotka saavat aidan yli heittävän ulkoistamisen näyttämään hyvältä, korvautuvat ominaisuuden läpimenoajalla, virheiden karkaamisella ja uudelleentyöhön käytettyjen ulkomaisten tuntien osuudella, niillä luvuilla, jotka paljastavat, tekeekö komento työnsä.

On olemassa toinen siirtymä, siinä, missä kokeneisuus sijaitsee. Aidan yli heittävä ulkoistaminen pyrkii lähettämään kiinnostavan, kokeneisuutta vaativan työn ulkomaille muun mukana ja pitämään nuoren koordinointikerroksen kotona; komentokeskusmalli kääntää tämän päinvastoin pitäen kokeneisuuden kotimaassa, missä konteksti on, ja antaen ulkomaisen tiimin olla erinomainen toteutuksessa ilman, että sitä pyydetään tuottamaan kontekstia, jota sillä ei voi olla. Tämä tulkitaan usein väärin epäluottamukseksi ulkomaista tiimiä kohtaan. Se on päinvastoin: se on järjestely, joka antaa kyvykkään ulkomaisen tiimin tehdä parasta työtään, kun siltä ei pyydetä ratkaisemaan moniselitteisyyksiä, joita kukaan sen etäisyydeltä ei voisi ratkaista hyvin, ja kun sille annetaan riittävän selkeät määrittelyt, että sen osaaminen kuluu rakentamiseen eikä arvailuun.

10. Vastaväitteet ja vastaukset

Komentokeskus vain lisää kotimaista kustannusta ja nakertaa säästöä. Se lisää kotimaista kustannusta ja nostaa nettosäästöä, mikä on yhtälön (5) koko pointti: useimmat epäonnistuvat toimeksiannot sijaitsevat kaukana $r^\ast$:n vasemmalla puolella, missä hieman enemmän komentoa poistaa paljon enemmän uudelleentyötä kuin se maksaa. Komentokeskus ei ole säästön yleiskustannus; se on mekanismi, joka muuntaa bruttosäästön nettosäästöksi. Yrityksen, joka on aidosti jo kohdassa $r^\ast$, ei tulisi lisätä komentoa; lähes mikään ei ole.

Jos kaikki on määriteltävä niin tarkasti, miksei sitä vain rakenneta kotimaassa? Koska määrittelyllä ja rakentamisella on hyvin erilaiset kustannukset ja hyvin erilaiset niukkuudet. Määrittely on pieni määrä kokenutta, kontekstisidonnaista työtä; rakentaminen on suuri määrä työtä, joka ei ole kontekstisidonnaista, kun se on kerran määritelty. Malli lähettää suuren, edullisesti sijoitettavan määrän sinne, missä se on edullista, ja pitää kotona vain pienen, kontekstisidonnaisen määrän. Näiden kahden lysähdyttäminen takaisin yhteen hylkää juuri sen arbitraasin, joka on todellinen.

Nykyaikaiset työkalut ja videopuhelut ovat tehneet etäisyydestä merkityksettömän. Ne ovat tehneet siitä pienemmän, eivät merkityksetöntä, ja todisteet siitä, että etäisyydellä on yhä väliä, ovat vankkoja (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Työkalut laskevat ylityksen kustannusta; ne eivät poista sitä päivää, jonka kello lisää edestakaiseen matkaan, eivätkä palauta sitä epämuodollista, ympäröivää viestintää, jota samassa paikassa olevat tiimit käyttävät moniselitteisyyden ratkaisemiseen huomaamattaan. Komentokeskus on se rakenteellinen vastaus, jota työkalut täydentävät mutta eivät korvaa.

Ulkomainen kumppanimme on erittäin kyvykäs ja voi omistaa koko asian. Kyvykkyys ei ole ongelma; konteksti on. Erittäin kyvykäskään ulkomainen tiimi ei voi ratkaista moniselitteisyyttä, jonka ratkaiseminen edellyttää tietoa siitä, mitä liiketoiminta tarkoitti, ja sen pyytäminen asettaa sen osaamisen sellaista ongelmaa vastaan, jonka etäisyys tekee ratkeamattomaksi. Malli pitää vastuun kotimaassa ei siksi, että ulkomainen tiimi olisi heikko, vaan siksi, että vastuu on sidottu kontekstiin, joka on kotimaassa.

11. Rajoitukset

Tämä on käytännön toimijoille suunnattu argumentti, jolla on tarkoituksellisesti yksinkertainen malli, ja sen rajat tulisi olla selvät. Lukujen 5–7 malli on havainnollistava: yhtälön (1) jäännösepämääräisyyden muoto, yhtälön (3) eksponentiaalinen uudelleentyön kerroin ja yhtälön (5) yksittäinen optimaalinen suhde ovat luettavuuden vuoksi valittuja yksinkertaistuksia, eikä vakioita $a$, $b$, $w_c$ ja $w_o$ mitata tässä; yritys voi arvioida ne omasta uudelleentyö- ja hinta-aineistostaan, ja odottaisimme laadullisen muodon, sisäisen optimin, joka liikkuu moniselitteisyyden ja suhteellisen kustannuksen myötä, säilyvän silläkin, missä tarkka muoto ei säily. Argumentti on rajattu työhön, jonka moniselitteisyydet voidaan ponnistellen ratkaista määrittelyksi; aidosti tutkimuksenkaltainen työ, jossa kukaan ei vielä tiedä, mikä on oikein, sopii malliin huonosti ja sen tulisi enimmäkseen pysyä samassa paikassa. Artikkeli nojaa Intiaan, koska siellä on tarjonnan syvyys ja käytännön mittakaava, mutta mikään mallissa ei ole maakohtaista; se pätee mihin tahansa kotimaisen–ulkomaisen jakoon todellisen etäisyyden ja kellon yli. Ja malli olettaa yrityksen, joka ylipäätään kykenee miehittämään kokeneen komentokerroksen; yrityksen, joka ei kykene, tulisi olla rehellinen siitä, ettei se vielä osaa ulkoistaa hyvin, sen sijaan että se ulkoistaa huonosti ja kutsuu tulosta tuomioksi Intiasta.

12. Johtopäätös

IT-työn ulkoistaminen Intiaan tuottaa pettymyksen yrityksille, jotka ulkoistavat väärän asian: ne lähettävät vastuun yhdessä toteutuksen kanssa, irrottavat työn siitä kontekstista ja harkinnasta, jotka tekevät siitä oikeaa, ja katsovat sitten, kun uudelleentyö ja kello syövät sen säästön, jota ne tulivat hakemaan. Korjaus ei ole työn tuominen kotiin vaan sen jakaminen oikein, pitäen kotimaassa sen ohuen, kokeneen komennon, jonka on pysyttävä liiketoiminnan vieressä, päättäen, mitä rakennetaan, omistaen arkkitehtuurin ja rajapinnat, muuntaen tarkoituksen määrittelyksi ja pitäen hallussaan hyväksynnän, kun taas toteutus skaalautuu Intiassa, missä osaamista on runsaasti ja edullisesti. Mihin raja vedetään, on kysymys, johon tehtävän jäännösepämääräisyys vastaa, ja komentokeskuksen taito on nostaa määrittelyä, kunnes tuo epämääräisyys on riittävän pieni ylittämään kuilun; kuinka paljon komentoa pidetään, on kysymys, jolla on todellinen optimi, positiivinen ja äärellinen, joka nousee työn moniselitteisyyden myötä ja laskee komennon kallistuessa. Näin tehtynä etäisyys lakkaa olemasta vero ja kahdentoista tunnin kellosta tulee toinen työvuoro, ja se arbitraasi, joka oli aina todellinen, saadaan vihdoin talteen. Ulkoista rakentaminen; komenna sitä kotoa. Yritys, joka muistaa, kumpi näistä kahdesta on sidottu kontekstiin ja kumpi ei, voi hallita ulkoistamisen Intiaan; yritys, joka unohtaa, päätyy yhä uudelleen, väärin, siihen johtopäätökseen, että ongelma oli linjan toinen pää.

Liite A. Komentokeskuksen pystyttäminen

Alla olevat käytännöt ovat se, mikä pitää luvun 4 jaon koossa käytännössä. Mikään ei ole uutta; kurinalaisuus on arvo.

Lähteet

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.