1. Pendahuluan

Selama dua dekade, tawarannya selalu sama dan hitung-hitungannya tampak tak tertolak. Seorang insinyur di India berbiaya sebagian kecil dari insinyur di Eropa Barat atau Amerika Serikat, pasokan mereka besar dan terlatih baik, dan bahasa Inggris adalah bahasa kerja, sehingga perusahaan yang memindahkan pekerjaan perangkat lunaknya ke sana seharusnya, di atas kertas, mengerjakan pekerjaan yang sama dengan biaya jauh lebih murah. Banyak sekali pekerjaan telah berpindah justru dengan penalaran itu, dan India telah membangun industri jasa TI kelas dunia di atasnya. Namun hasilnya, dari perusahaan ke perusahaan, sangat tidak merata: beberapa organisasi memperoleh perangkat lunak yang sangat baik dari India selama bertahun-tahun, sementara yang lain memperoleh tagihan yang terus naik, kualitas pengiriman yang terus turun, dan aliran cacat yang tak pernah benar-benar tertutup oleh gaji yang dihemat, hingga mereka menyatakan offshoring sebagai kegagalan dan membawa pekerjaan itu pulang, sering kali dengan menyimpulkan bahwa masalahnya adalah India. Masalahnya bukan India.

Masalahnya adalah perusahaan meng-offshore hal yang salah. Intuisi di balik offshoring adalah bahwa pengembangan perangkat lunak merupakan eksekusi, sejumlah pekerjaan yang dapat diukur dalam jam-orang dan dibeli di mana pun jam-orang paling murah, dan atas dasar intuisi itu sebuah perusahaan menyerahkan sebuah spesifikasi dan jumlah tenaga kerja lalu menunggu keluaran. Namun pengembangan perangkat lunak pada dasarnya bukanlah eksekusi; ia adalah penyelesaian seribu ambiguitas kecil, yang masing-masing menuntut pengetahuan tentang apa yang sebenarnya dimaksud bisnis, bagaimana bagian ini seharusnya cocok dengan keseluruhan, dan apa arti “selesai” yang sesungguhnya di sini, dan pengetahuan itu berada di tempat bisnis berada, bukan di tempat papan ketik berada. Ketika sebuah perusahaan meng-offshore eksekusi, tanpa sadar ia juga meng-offshore keputusan-keputusan itu, kepada orang-orang yang paling jauh dari konteks yang dibutuhkan untuk membuatnya dengan baik, dan hasilnya adalah pekerjaan yang masuk akal secara lokal namun salah secara global, ditemukan terlambat, melintasi jeda dua belas jam, dan diperbaiki dengan lambat. Arbitrase tenaga kerja itu nyata; koordinasi dan pengerjaan ulang yang dipicunya, jika ditangani dengan buruk, lebih besar.

Makalah ini membahas model operasi yang memperbaiki kesalahan tersebut dengan cara tidak membuatnya, dan model itu memiliki nama yang akan kami gunakan sepanjang tulisan: command centre onshore. Idenya adalah memisahkan, secara sengaja dan struktural, dua hal yang disatukan oleh offshoring yang naif. Yang satu adalah eksekusi, yakni pembangunan, yang memang benar-benar dapat dan seharusnya diperbesar di tempat talenta melimpah dan terjangkau, yaitu di India. Yang lain adalah command: memutuskan apa yang dibangun dan dalam urutan apa, memiliki arsitektur dan antarmuka antarbagian, mengubah apa yang samar-samar diinginkan bisnis menjadi spesifikasi yang cukup presisi untuk dibangun dari jauh tanpa percakapan, dan menilai apakah yang kembali itu benar. Command bersifat kecil, senior, dan mahal, dan ia tetap di onshore, berdampingan dengan bisnis yang intent-nya ia ada untuk dibawa. Tesisnya adalah bahwa keberhasilan sebuah program offshoring hampir sepenuhnya ditentukan oleh apakah lapisan command ini ada dan baik, dan hampir tidak sama sekali oleh kemampuan mentah tim offshore, yang biasanya baik-baik saja; dan bahwa perusahaan gagal karena kurang berinvestasi pada command justru karena command adalah bagian onshore yang mahal yang seharusnya dihapus oleh offshoring.

Kontribusinya adalah sebuah argumen dan sebuah model kecil, bukan tolok ukur. Bagian 2 menempatkan klaim ini terhadap rekam jejak offshoring dan rekayasa perangkat lunak global. Bagian 3 mendiagnosis kegagalan yang sesungguhnya, yakni meng-offshore tanggung jawab alih-alih sekadar eksekusi. Bagian 4 menggambarkan command centre dan apa yang dimilikinya. Bagian 5 memberikan model tentang di mana garis antara command dan delivery seharusnya jatuh, yang bergantung pada context load dan specification completeness. Bagian 6 membahas jam, dan bagaimana follow-the-sun menjadi daya ungkit alih-alih latensi. Bagian 7 menurunkan command ratio optimal. Bagian 8 menelusuri sebuah kasus yang dikonstruksi; Bagian 9 hingga 12 menarik konsekuensinya, menjawab keberatan, menyatakan batasan, dan menyimpulkan. Pertanyaan yang menyeluruh adalah: apa yang harus dipertahankan perusahaan di dalam negeri, dan seberapa banyak, agar pekerjaan yang dikirimnya ke India kembali dengan benar?

2. Latar belakang

2.1 Rekam jejak offshoring

Pengalihdayaan (outsourcing) dan offshoring TI memiliki salah satu literatur empiris terbesar dalam sistem informasi, dan vonisnya bukanlah bahwa offshoring tidak menguntungkan melainkan bahwa keuntungannya bergantung pada bagaimana ia dikelola. Lacity, Khan, dan Willcocks (2009), yang meninjau dua dekade studi, menemukan bahwa kapabilitas klien dan pemasok, desain kontrak, dan manajemen hubungan, bukan selisih upah semata, yang menjelaskan rentang antara keterlibatan yang berhasil dan yang gagal. Carmel dan Tjia (2005) memberikan catatan praktisi tentang sourcing ke tenaga kerja global dan mengatalogkan cara-cara jarak menggerus arbitrase; Sahay, Nicholson, dan Krishna (2003) memberikan uraian sepanjang buku tentang pengembangan perangkat lunak melintasi batas India, dan Oshri, Kotlarsky, dan Willcocks (2007) menelusuri bagaimana sebuah vendor India terkemuka menata model pengiriman global di seputar keahlian yang tersebar. Rottman dan Lacity (2006) menyarikan praktik-praktik yang terbukti dan menemukan bahwa perusahaan-perusahaan yang berhasil berinvestasi besar pada pekerjaan onshore berupa menyusun spesifikasi, mengoordinasikan, dan mengatur tata kelola, justru pekerjaan yang dalam makalah ini disebut command. Temuan yang konsisten adalah bahwa penghematan itu bersifat kotor, bukan bersih, dan bahwa yang berdiri di antara keduanya adalah upaya manajemen yang sebagian besar tetap berada di dalam negeri.

2.2 Mengapa jarak itu mahal

Literatur kedua, tentang pengembangan perangkat lunak yang terdistribusi secara global, menjelaskan mekanismenya. Herbsleb dan Mockus (2003), dalam studi yang paling sentral bagi makalah ini, menunjukkan secara empiris bahwa butir-butir pekerjaan yang membutuhkan orang di berbagai lokasi memakan waktu jauh lebih lama untuk diselesaikan dibandingkan butir setara di satu lokasi, dan menelusuri keterlambatan itu pada biaya dan latensi komunikasi yang dituntut oleh koordinasi lintas lokasi. Ramasubbu dan Balan (2007), yang meneliti proyek-proyek yang tersebar antara India dan Amerika Serikat, mengukur penalti yang sama secara langsung pada kinerja proyek. Olson dan Olson (2000) memberikan hasil umum di bawah judul “distance matters”: pekerjaan yang terkolokasi memperoleh manfaat dari komunikasi yang cepat, kaya, dan informal yang hilang pada pekerjaan terdistribusi, dan tak ada perkakas yang memulihkannya sepenuhnya. Kraut dan Streeter (1995) telah lebih dahulu menunjukkan betapa besar bagian pengembangan perangkat lunak yang berupa koordinasi alih-alih pengodean, dan Brooks (1975) jauh sebelumnya telah memberikan alasan mengapa menambah orang ke pekerjaan terdistribusi dapat memperlambatnya: jalur komunikasi tumbuh lebih cepat daripada orangnya. Pelajarannya bukanlah bahwa pengembangan terdistribusi tidak dapat berjalan, melainkan bahwa setiap batas yang harus dilintasi sepotong pekerjaan memiliki harga, dan harga itu dibayar dalam waktu dan cacat.

2.3 Hukum Conway dan arsitektur batas

Gagasan terdalam yang menjadi sandaran makalah ini adalah gagasan Conway (1968): struktur sebuah sistem akhirnya mencerminkan struktur komunikasi organisasi yang membangunnya. Korolarinya untuk offshoring bersifat persis dan kurang dimanfaatkan. Jika offshore dan onshore adalah dua kelompok yang berkomunikasi secara longgar, maka perangkat lunak akan paling bersih ketika batas antara keduanya jatuh di sepanjang sambungan arsitektural yang sejati, sebuah modul dengan antarmuka yang terdefinisi, dan akan paling bermasalah di tempat satu gumpalan pekerjaan yang terkopel erat dipecah melintasi jeda. Herbsleb dan Grinter (1999) mengonfirmasi hal ini secara langsung, menemukan bahwa pengembangan terdistribusi berhasil ketika arsitektur cukup modular sehingga tiap lokasi memiliki satu bagian dan antarmuka antarbagian bersifat eksplisit, dan menjadi sulit ketika tidak demikian. Parnas (1972) memberikan disiplin desain, yakni penyembunyian informasi, yang memungkinkan modul semacam itu. Konsekuensi praktisnya, yang dikembangkan di Bagian 4, adalah bahwa memiliki arsitektur bukanlah salah satu tugas command centre di antara banyak tugas; ia adalah tugas yang memungkinkan semua tugas lainnya, karena ia memutuskan di mana batas yang mahal itu jatuh.

3. Kegagalan yang sesungguhnya: meng-offshore tanggung jawab

Kegagalan offshoring yang khas bukanlah pengetikan yang lambat; melainkan pekerjaan yang diselesaikan dengan penuh percaya diri namun diam-diam salah. Sebuah kebutuhan diserahkan yang lengkap di kepala pengirim namun ambigu di atas kertas, karena pengirim berbagi konteks dengan bisnis yang tidak dimiliki penerima. Insinyur offshore, yang kompeten dan bersedia, menyelesaikan ambiguitas itu dengan satu-satunya cara yang tersedia dari dua belas zona waktu jauhnya: dengan menerka, secara masuk akal, lalu membangun. Terkaan itu baru ketahuan salah pada saat penerimaan, jika ada penerimaan, atau di produksi, jika tidak ada, dan koreksinya melintasi jeda dua kali, sekali untuk menjelaskan dan sekali untuk memverifikasi, tiap lintasan satu hari yang hilang karena jam. Kalikan ini dengan setiap ambiguitas dalam sistem nyata dan arbitrase itu lenyap, bukan karena ada yang berlaku tidak kompeten, melainkan karena keputusan yang membutuhkan konteks dibuat di tempat yang tak memilikinya.

Yang telah terjadi, dalam bahasa makalah ini, adalah bahwa perusahaan meng-offshore tanggung jawab padahal yang dimaksudkannya hanyalah meng-offshore eksekusi. Tanggung jawab atas sepotong perangkat lunak adalah otoritas terakumulasi untuk menyelesaikan ambiguitasnya dengan benar: mengetahui apa yang dimaksud bisnis, memutuskan bagaimana bagian itu melayani keseluruhan, menyatakan apa itu “benar”. Otoritas itu tak terpisahkan dari konteks, dan konteks bersifat lokal. Eksekusi, yakni pembangunan suatu hal begitu ambiguitasnya diselesaikan, tidak terikat konteks dan mudah berpindah. Kesalahannya adalah memperlakukan keduanya sebagai satu paket dan mengirimkannya bersama-sama; perbaikannya adalah memisahkannya, menjaga tanggung jawab tetap onshore tempat konteksnya hidup, dan mengirim ke offshore hanya eksekusi, dengan ambiguitasnya yang telah diselesaikan menjadi spesifikasi. Semua yang menyusul adalah penjabaran tentang bagaimana membuat pemisahan itu dan di mana.

4. Command centre

Command centre onshore adalah rumah organisasional bagi tanggung jawab yang tidak boleh berpindah. Ia sengaja dibuat kecil dan sengaja senior, karena daya ungkitnya berasal dari kualitas segelintir keputusan alih-alih kuantitas keluaran, dan ia berdampingan dengan bisnis, bukan dengan papan ketik. Gambar 1 menggambarkan modelnya dan Tabel 3 membagi pekerjaannya. Command centre memiliki lima hal, dan disiplin modelnya adalah bahwa ia memiliki kelima hal itu dan berupaya tidak memiliki apa pun selain itu.

Dari intent ke spesifikasi. Produk pertama command centre bukanlah perangkat lunak melainkan spesifikasi: penerjemahan apa yang samar-samar diinginkan bisnis menjadi uraian yang cukup presisi untuk dibangun oleh seseorang yang tak bisa mencondongkan badan dan bertanya. Inilah pekerjaan yang menyelesaikan ambiguitas di tempat konteksnya berada, agar tak ada yang harus diselesaikan di tempat konteksnya tidak ada, dan ini adalah aktivitas dengan daya ungkit tertinggi dalam seluruh model, karena setiap ambiguitas yang tertinggal dalam spesifikasi dibayar kemudian dengan biaya penuh satu perjalanan pulang-pergi melintasi jeda.

Arsitektur dan antarmuka. Menurut hukum Conway, perangkat lunak akan retak di sepanjang sambungan komunikasi organisasi, sehingga command centre memiliki arsitektur justru untuk memilih di mana sambungan itu jatuh: ia menguraikan sistem menjadi modul-modul dengan antarmuka eksplisit sehingga tiap pod offshore memiliki satu bagian yang dapat dibangunnya dengan sedikit ketergantungan lintas-batas. Menggambar batas dengan baik adalah yang mengubah jarak dari pajak yang dibayar pada setiap interaksi menjadi pajak yang dibayar hanya pada beberapa antarmuka yang terdefinisi baik.

Penentuan prioritas. Apa yang dibangun lebih dahulu adalah penilaian bisnis, bukan penilaian pengiriman, dan itu tetap berada pada command centre, yang memegang satu backlog tunggal beserta urutannya. Menyebarkan penentuan prioritas ke tim offshore, atau ke beberapa pemangku kepentingan sekaligus, memperkenalkan kembali melintasi jeda justru koordinasi yang keberadaan modelnya untuk membendungnya.

Penerimaan dan gerbang mutu. Command centre memutuskan apa itu “selesai” dan menguji pekerjaan yang kembali terhadapnya, memegang gerbang yang dipercayai bisnis. Ini adalah pasangan dari spesifikasi: setelah mendefinisikan kebenaran di muka, ia memverifikasinya saat kembali, dan karena ia berada di onshore dan dekat dengan bisnis, ia dapat menilai kelaikan, bukan sekadar fungsi.

Satu pemilik yang akuntabel. Akhirnya, command centre adalah tempat akuntabilitas tak terbagi: seorang pemilik tunggal yang bertanggung jawab kepada bisnis atas apa yang disampaikan, yang tak bisa menunjuk ke seberang jeda. Akuntabilitas yang terbelah melintasi batas adalah akuntabilitas yang telah hilang, dan mengembalikannya ke satu titik onshore adalah sebagian besar dari yang membuat model ini dapat ditatakelola.

5. Menarik garis

Jika command tetap onshore dan eksekusi pergi ke offshore, segalanya bergantung pada di mana garis antara keduanya ditarik, tugas demi tugas. Model yang mengatur pilihan ini memiliki dua sumbu. Yang pertama adalah context load sebuah tugas: seberapa banyak pengetahuan lokal, tacit, dan spesifik-bisnis yang dibutuhkan untuk menyelesaikannya dengan benar, tinggi untuk perubahan yang menyentuh aturan regulasi yang halus atau komitmen pelanggan yang telah lama berdiri, rendah untuk komponen yang terbatas baik dengan kontrak yang jelas. Yang kedua adalah specification completeness yang dapat diberikan command centre padanya: seberapa penuh ambiguitasnya dapat diselesaikan di muka, di atas kertas, tanpa percakapan. Sebuah tugas aman untuk di-offshore ketika ambiguitas residual yang mencapai pod offshore, yakni context load-nya dikurangi specification completeness yang diterapkan padanya, kecil. Dengan menuliskan $\kappa$ untuk context load dan $s$ untuk specification completeness, keduanya pada skala yang sama, residualnya adalah

dan $\alpha$-lah, bukan tingkat kesulitan mentah dari pekerjaan, yang memprediksi pengerjaan ulang. Model ini memiliki pembacaan manajerial yang tajam, yang digambar dalam Tabel 1. Tugas berkonteks rendah di-offshore dengan bersih berapa pun tingkat kesulitan teknisnya. Tugas berkonteks tinggi bukan tidak cocok untuk di-offshore; ia tidak cocok untuk di-offshore tanpa spesifikasi, dan tugas command centre adalah menaikkan $s$ hingga $\alpha$ cukup kecil untuk dikirim. Di tempat context load benar-benar tak dapat dikurangi, di tempat pengetahuan sama sekali tak dapat dituliskan, tugas itu tetap onshore, dan mengakui hal itu secara jujur adalah bagian dari disiplin. Mode kegagalan yang dinamai model ini adalah tugas berkonteks tinggi yang dikirim dengan spesifikasi berkelengkapan rendah: ambiguitas residual maksimum, diselesaikan secara offshore dengan terkaan, pada jarak maksimum.

6. Jam

Perbedaan waktu antara bisnis Barat dan India, sekitar sembilan hingga dua belas jam, adalah fitur yang paling sering diperlakukan praktisi sebagai beban murni dan yang paling bersih dapat diubah command centre menjadi aset. Jika dibiarkan, jeda itu adalah latensi: pertanyaan yang diajukan pada akhir hari offshore dijawab pada akhir hari onshore, dan satu klarifikasi tunggal memakan satu hari kalender apa pun substansinya, sehingga rantai klarifikasi memakan seminggu untuk menyelesaikan satu jam isi yang sesungguhnya. Inilah mekanisme yang membuat offshoring yang dikelola buruk terasa lambat bahkan ketika semua orang bekerja keras: jalur kritis berjalan melalui jeda, dan jeda menambahkan satu hari per lintasan.

Dijalankan dengan baik, jeda yang sama adalah giliran kerja kedua. Jika command centre menyerahkan pekerjaan yang ambiguitasnya telah diselesaikan, pod offshore mengeksekusinya sepanjang malam onshore dan mengembalikan hasilnya pada pagi onshore, dan hari yang dilewati bisnis dalam tidur menjadi hari kemajuan alih-alih hari menunggu. Perbedaan antara kedua hasil itu sepenuhnya adalah ambiguitas residual $\alpha$ dari apa yang diserahkan: penyerahan dengan $\alpha \approx 0$ tak membutuhkan perjalanan pulang-pergi dan jam menjadi keuntungan murni; penyerahan yang penuh pertanyaan tak terjawab membalikkan jam melawan Anda, karena tiap pertanyaan berarti satu hari penuh. Cara kasar untuk melihatnya adalah bahwa percepatan efektif dari giliran kerja kedua adalah

dengan $\eta$ mengukur seberapa bersih pekerjaan dapat diserahkan dan $\alpha$ adalah ambiguitas residual dari persamaan (1); ketika $\alpha\to 0$ jam mendekati satu giliran kerja tambahan yang sejati, dan ketika $\alpha$ naik keuntungan itu runtuh lalu berbalik menjadi pajak satu-hari-per-pertanyaan. Command centre memperoleh jam dengan memiliki spesifikasi dan definisi “selesai” yang membuat $\alpha$ kecil, itulah sebabnya follow-the-sun adalah konsekuensi dari command yang baik, bukan trik penjadwalan yang dapat dibeli terpisah.

7. Command ratio

Seberapa banyak command yang cukup? Pertanyaan ini memiliki jawaban yang nyata, dan jawabannya bukan “sesedikit mungkin”, naluri yang menghasilkan offshoring lempar-ke-seberang-tembok, maupun “sebanyak mungkin”, yang membangun kembali di onshore biaya yang seharusnya dilepas oleh offshoring. Misalkan $r$ adalah command ratio, yaitu kapasitas command centre onshore sebagai fraksi dari kapasitas pengiriman offshore yang ditatakelolanya. Command berbiaya tarif onshore yang tinggi $w_c$ per unit; pengiriman berbiaya tarif offshore yang rendah $w_o$ per unit. Nilai command adalah bahwa ia menurunkan ambiguitas residual yang mencapai pod dan karenanya pengerjaan ulang yang harus mereka lakukan: lebih banyak command berarti lebih banyak pekerjaan yang dispesifikasikan, ditinjau, dan digerbang sebelum dan sesudah melintasi jeda, dan karenanya pengali pengerjaan ulang yang lebih rendah pada pekerjaan yang disampaikan. Bentuk yang berguna untuk pengali itu adalah

dengan $a$ menskalakan pengerjaan ulang yang akan timbul tanpa command sama sekali, ditetapkan oleh ambiguitas intrinsik pekerjaan, dan $b$ mengukur seberapa efektif command dikonversi menjadi ambiguitas yang terselesaikan. Total biaya untuk menyampaikan satu unit pekerjaan yang selesai, yakni command ditambah pengiriman yang telah dikerjakan ulang, kemudian adalah

yaitu jumlah dari suku yang menaik, yakni biaya command, dan suku yang menurun, yakni pengerjaan ulang yang dicegah command, sehingga ia memiliki satu minimum interior tunggal. Menetapkan $C'(r)=0$ menghasilkan command ratio yang meminimalkan biaya

yang merupakan hasil kuantitatif sentral makalah ini. Ia menyatakan tiga hal yang dapat ditindaklanjuti seorang manajer. Jumlah command yang optimal bernilai positif: $r^\ast > 0$ kapan pun $w_o a b > w_c$, yaitu kapan pun command sedikit saja efektif dan ambiguitas sedikit saja nyata, sehingga melempar pekerjaan ke seberang tembok ($r = 0$) tak pernah optimal. Ia berhingga: command melampaui $r^\ast$ berbiaya lebih besar daripada pengerjaan ulang yang dihematnya, sehingga menahan segalanya di onshore pun tidak optimal. Dan ia bergerak ke arah yang benar: $r^\ast$ naik seiring ambiguitas pekerjaan ($a$) dan seiring seberapa baik command menyelesaikannya ($b$), serta turun seiring command onshore menjadi mahal relatif terhadap pengiriman offshore ($w_c/w_o$), sehingga portofolio yang ambigu dan berkonteks tinggi menuntut lapisan command yang lebih tebal dan portofolio yang sederhana serta terbatas baik menuntut yang lebih tipis. Gambar 2 menggambar $C(r)$ dan dua rezim kegagalan di kedua sisi optimum.

8. Sebuah kasus yang dikonstruksi

Kasus ini dikonstruksi, bukan diamati: angka-angkanya bersifat ilustratif dan konsisten secara internal, dan ia dimaksudkan untuk menunjukkan kuantitas model mengambil nilai yang masuk akal alih-alih melaporkan sebuah hasil. Sebuah grup Barat menjalankan pengembangan aplikasi untuk sistem back-office-nya dan, tiga tahun lalu, meng-offshore sebagian besarnya ke sebuah vendor di India atas dasar staff augmentation: ia mempertahankan segelintir manajer proyek onshore, menulis kebutuhan dalam bentuk yang selama ini selalu digunakannya, dan mengukur keberhasilan dari jumlah tenaga kerja yang dipindahkan dan tarif harian yang dihemat. Di atas kertas, ia telah memangkas separuh biaya seorang pengembang. Dalam praktiknya, pengiriman fitur secara langsung dari ujung ke ujung, dari permintaan hingga perubahan produksi yang diterima, justru memanjang, tingkat lolosnya cacat ke produksi naik, dan bagian yang besar dan terus bertambah dari jam kerja tim offshore tersedot ke pengerjaan ulang fitur yang telah dibangun berdasarkan pembacaan yang masuk akal namun salah atas kebutuhan yang ambigu. Penghematannya kotor; secara bersih, ia tipis dan terus menurun. Tabel 2 memberikan kolom sebelum.

Grup itu kemudian membangun ulang keterlibatan ini di seputar sebuah command centre. Ia tidak mengganti vendor atau memindahkan pekerjaan pulang; ia menambahkan lapisan onshore yang tipis dan senior, beberapa persen dari total jumlah tenaga kerja, yang mengambil kepemilikan atas lima hal dari Bagian 4: ia menulis ulang kebutuhan sebagai spesifikasi dengan kriteria penerimaan yang eksplisit, memotong ulang arsitektur sehingga tiap pod offshore memiliki satu modul di balik antarmuka yang terdefinisi, memegang satu backlog tunggal yang terurut, dan menjalankan gerbang penerimaan sebelum apa pun mencapai produksi. Tim offshore dan tarifnya tak berubah; yang berubah adalah ambiguitas residual $\alpha$ yang mencapainya. Pengerjaan ulang turun seiring spesifikasi menyelesaikan terkaan yang telah mendorongnya, tingkat lolosnya cacat turun seiring gerbang menangkap apa yang biasa disembunyikan jeda, dan jam berubah dari latensi menjadi giliran kerja kedua seiring penyerahan berhenti membutuhkan perjalanan pulang-pergi. Biaya command yang ditambahkan hanyalah sebagian kecil dari pengerjaan ulang yang dihapusnya, dan itulah persamaan (5) dalam praktik: keterlibatan ini telah berjalan jauh di sebelah kiri $r^\ast$, dan bergerak ke arahnya menurunkan biaya total meskipun menaikkan biaya onshore. Tabel 2 menelusuri perubahan itu.

9. Apa yang berubah bagi model operasi

Mengadopsi command centre mengubah apa yang harus dikuasai sebuah perusahaan, dan perubahan itu tak nyaman karena ia berlawanan dengan naluri yang memotivasi offshoring. Penghematannya tetap nyata, tetapi ia hanya diraih dengan membelanjakan, di onshore dan pada tarif senior, pada lapisan command yang oleh kasus bisnis naif diperlakukan sebagai pemborosan untuk dihapus. Tabel 3 menjabarkan pembagian kerja yang dituntut model ini. Sumber daya yang langka menjadi segelintir orang senior yang dapat memegang intent, arsitektur, dan penerimaan dengan baik, dan kapasitas offshoring sebuah perusahaan dibatasi oleh berapa banyak orang semacam itu yang dimilikinya, bukan oleh berapa banyak insinyur offshore yang dapat dipekerjakannya. Metriknya pun berubah: jumlah tenaga kerja yang dipindahkan dan tarif harian yang dihemat, angka-angka yang membuat offshoring lempar-ke-seberang-tembok tampak baik, digantikan oleh waktu tunggu fitur, lolosnya cacat, dan pangsa jam offshore yang dihabiskan untuk pengerjaan ulang, yakni angka-angka yang mengungkap apakah command menjalankan tugasnya.

Ada pergeseran kedua, dalam hal di mana senioritas berada. Offshoring lempar-ke-seberang-tembok cenderung mengirim pekerjaan yang menarik dan senior ke offshore bersama sisanya dan mempertahankan lapisan koordinasi junior di dalam negeri; model command centre membalikkannya, menjaga senioritas tetap onshore tempat konteksnya berada dan membiarkan tim offshore menjadi unggul dalam eksekusi tanpa diminta memasok konteks yang tak mungkin dimilikinya. Ini sering disalahbaca sebagai ketidakpercayaan pada tim offshore. Sebaliknya: inilah pengaturan yang memungkinkan tim offshore yang cakap melakukan pekerjaan terbaiknya, dengan tidak memintanya menyelesaikan ambiguitas yang tak akan dapat diselesaikan dengan baik oleh siapa pun pada jaraknya, dan dengan memberinya spesifikasi yang cukup jelas sehingga kompetensinya dihabiskan untuk membangun alih-alih menerka.

10. Keberatan dan jawaban

Command centre hanya menambah biaya onshore dan menggerus penghematan. Ia menambah biaya onshore dan menaikkan penghematan bersih, dan itulah inti seluruh persamaan (5): sebagian besar keterlibatan yang gagal duduk jauh di sebelah kiri $r^\ast$, tempat sedikit tambahan command menghapus jauh lebih banyak pengerjaan ulang daripada biayanya. Command centre bukanlah beban tambahan atas penghematan; ia adalah mekanisme yang mengubah penghematan kotor menjadi penghematan bersih. Perusahaan yang benar-benar sudah berada di $r^\ast$ tidak seharusnya menambah command; hampir tak ada yang demikian.

Jika Anda harus menspesifikasikan segalanya begitu presisi, mengapa tidak sekalian membangunnya di onshore saja? Karena spesifikasi dan pembangunan memiliki biaya yang sangat berbeda dan kelangkaan yang sangat berbeda. Spesifikasi adalah sejumlah kecil pekerjaan senior yang terikat konteks; pembangunan adalah sejumlah besar pekerjaan yang tidak terikat konteks begitu dispesifikasikan. Model ini mengirim kuantitas besar yang murah untuk ditempatkan ke tempat ia terjangkau dan hanya menyimpan kuantitas kecil yang terikat konteks di dalam negeri. Menyatukan keduanya kembali berarti melepaskan justru arbitrase yang nyata itu.

Perkakas modern dan panggilan video telah membuat jarak tak relevan. Mereka telah membuatnya lebih kecil, bukan tak relevan, dan bukti bahwa jarak masih berpengaruh bersifat kuat (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Perkakas menurunkan biaya satu lintasan; ia tidak menghapus satu hari yang ditambahkan jam pada perjalanan pulang-pergi, maupun memulihkan komunikasi informal dan ambien yang digunakan tim terkolokasi untuk menyelesaikan ambiguitas tanpa menyadarinya. Command centre adalah jawaban struktural yang dilengkapi perkakas tetapi tidak digantikannya.

Mitra offshore kami sangat cakap dan dapat memiliki keseluruhannya. Kecakapan bukanlah persoalannya; konteks-lah persoalannya. Tim offshore yang sangat cakap pun tetap tak dapat menyelesaikan ambiguitas yang penyelesaiannya menuntut pengetahuan tentang apa yang dimaksud bisnis, dan memintanya melakukan itu berarti mengadu kompetensinya dengan persoalan yang dibuat jarak menjadi tak terpecahkan. Model ini menjaga tanggung jawab tetap onshore bukan karena tim offshore lemah melainkan karena tanggung jawab terikat pada konteks yang berada di onshore.

11. Batasan

Ini adalah argumen yang ditujukan bagi praktisi dengan model yang sengaja dibuat sederhana, dan batasannya seharusnya gamblang. Model pada Bagian 5 hingga 7 bersifat ilustratif: bentuk ambiguitas-residual dari persamaan (1), pengali pengerjaan ulang eksponensial dari persamaan (3), dan rasio optimal tunggal dari persamaan (5) adalah penyederhanaan yang dipilih demi keterbacaan, dan konstanta $a$, $b$, $w_c$, dan $w_o$ tidak diukur di sini; sebuah perusahaan dapat mengestimasinya dari data pengerjaan ulang dan tarifnya sendiri, dan kami memperkirakan bentuk kualitatifnya, sebuah optimum interior yang bergerak seiring ambiguitas dan biaya relatif, akan bertahan bahkan di tempat bentuk persisnya tidak. Argumen ini dilingkupi pada pekerjaan yang ambiguitasnya dapat, dengan upaya, diselesaikan menjadi spesifikasi; pekerjaan yang benar-benar seperti riset, yang belum seorang pun tahu apa itu benar, cocok dengan model ini dengan buruk dan sebagian besar seharusnya tetap terkolokasi. Makalah ini menyandarkan diri pada India karena di sanalah kedalaman pasokan dan skala praktik berada, tetapi tak ada apa pun dalam model ini yang spesifik pada suatu negara; ia berlaku untuk pemisahan onshore–offshore apa pun melintasi jarak dan jam yang nyata. Dan model ini mengandaikan perusahaan yang mampu mengisi lapisan command senior sama sekali; perusahaan yang tak mampu seharusnya jujur bahwa ia belum mampu meng-offshore dengan baik, alih-alih meng-offshore dengan buruk dan menyebut hasilnya sebagai vonis atas India.

12. Kesimpulan

Offshoring pekerjaan TI ke India mengecewakan perusahaan yang meng-offshore hal yang salah: mereka mengirim keluar tanggung jawab bersama eksekusi, melepaskan pekerjaan dari konteks dan penilaian yang membuatnya benar, lalu menyaksikan pengerjaan ulang dan jam menggerogoti penghematan yang mereka datangi. Perbaikannya bukanlah membawa pekerjaan pulang melainkan memisahkannya dengan benar, menjaga tetap onshore command yang tipis dan senior yang harus berada di samping bisnis, memutuskan apa yang dibangun, memiliki arsitektur dan antarmuka, mengubah intent menjadi spesifikasi, dan memegang penerimaan, sementara eksekusi diperbesar di India tempat talenta melimpah dan terjangkau. Di mana menarik garis adalah pertanyaan yang dijawab oleh ambiguitas residual sebuah tugas, dan keahlian command centre adalah menaikkan spesifikasi hingga ambiguitas itu cukup kecil untuk melintasi jeda; seberapa banyak command yang harus dipertahankan adalah pertanyaan dengan optimum nyata, positif dan berhingga, yang naik seiring ambiguitas pekerjaan dan turun seiring command menjadi mahal. Dilakukan dengan cara ini, jarak berhenti menjadi pajak dan jam berselisih dua belas jam menjadi giliran kerja kedua, dan arbitrase yang memang selalu nyata akhirnya terjaga. Offshore-kan pembangunannya; command dari dalam negeri. Perusahaan yang mengingat mana dari keduanya yang terikat konteks, dan mana yang tidak, dapat menguasai offshoring ke India; perusahaan yang lupa akan terus menyimpulkan, secara keliru, bahwa masalahnya ada di ujung lain garis itu.

Lampiran A. Mendirikan command centre

Praktik-praktik berikut adalah yang membuat pemisahan pada Bagian 4 bertahan dalam praktik. Tak ada yang baru; disiplinnya-lah yang bernilai.

Referensi

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.