1. परिचय

दो दशकों से प्रस्ताव वही रहा है और गणित अप्रतिरोध्य दिखता रहा है। भारत में एक इंजीनियर की लागत पश्चिमी यूरोप या संयुक्त राज्य अमेरिका के एक इंजीनियर की लागत का एक अंश है, उनकी आपूर्ति बड़ी और सुप्रशिक्षित है, और अंग्रेज़ी कार्य-भाषा है, इसलिए जो कंपनी अपना सॉफ्टवेयर कार्य वहाँ ले जाती है, उसे कागज़ पर वही कार्य बहुत कम में कर लेना चाहिए। बहुत-सा काम ठीक इसी तर्क पर स्थानांतरित हुआ है, और भारत ने इस पर एक विश्वस्तरीय IT सेवा उद्योग खड़ा किया है। फिर भी परिणाम, कंपनी-दर-कंपनी, आश्चर्यजनक रूप से असमान हैं: कुछ संगठन वर्षों तक भारत से उत्कृष्ट सॉफ्टवेयर पाते हैं, जबकि अन्य को बढ़ता बिल, गिरती वितरण-गुणवत्ता और दोषों की एक धारा मिलती है जिसे बचाए गए वेतन कभी पूरी तरह ढक नहीं पाते, जब तक कि वे ऑफशोरिंग को विफलता घोषित न कर दें और काम घर वापस न ले आएँ, और अक्सर यह निष्कर्ष निकालें कि समस्या भारत थी। समस्या भारत नहीं थी।

समस्या यह है कि कंपनियाँ गलत चीज़ को ऑफशोर करती हैं। ऑफशोरिंग के पीछे की सहज बुद्धि यह है कि सॉफ्टवेयर विकास निष्पादन है, कार्य की एक मात्रा जिसे व्यक्ति-घंटों में मापा जा सकता है और जहाँ कहीं व्यक्ति-घंटे सबसे सस्ते हों वहाँ ख़रीदा जा सकता है, और इसी सहज बुद्धि पर कोई कंपनी एक विनिर्देश और एक कर्मचारी-संख्या सौंप देती है और उत्पादन की प्रतीक्षा करती है। परंतु सॉफ्टवेयर विकास मुख्यतः निष्पादन नहीं है; यह हज़ार छोटी-छोटी अस्पष्टताओं का समाधान है, जिनमें से प्रत्येक के लिए यह जानना आवश्यक है कि व्यवसाय का वास्तव में क्या अभिप्राय था, यह हिस्सा समूचे में कैसे बैठना चाहिए, और यहाँ ‘पूर्ण’ का सचमुच क्या अर्थ है, और यह ज्ञान वहाँ बसता है जहाँ व्यवसाय है, वहाँ नहीं जहाँ कीबोर्ड हैं। जब कोई कंपनी निष्पादन को ऑफशोर करती है तो वह अनजाने में उन निर्णयों को भी ऑफशोर कर देती है, उन लोगों को जो उन्हें भली-भाँति लेने के लिए आवश्यक संदर्भ से सबसे दूर हैं, और परिणाम ऐसा काम होता है जो स्थानीय रूप से विश्वसनीय और वैश्विक रूप से गलत है, देर से खोजा गया, बारह घंटे के अंतराल के पार, और धीरे-धीरे ठीक किया गया। श्रम मध्यस्थता वास्तविक है; उससे उत्पन्न समन्वय और पुनः-कार्य, जब बुरी तरह संभाला जाए, उससे बड़ा है।

यह शोध-पत्र उस संचालन मॉडल के बारे में है जो गलती न करके उसे ठीक करता है, और इस मॉडल का एक नाम है जिसका हम पूरे पत्र में प्रयोग करेंगे: ऑनशोर कमांड सेंटर। विचार यह है कि उन दो चीज़ों को जानबूझकर और संरचनात्मक रूप से अलग किया जाए जिन्हें एक भोली ऑफशोरिंग घालमेल कर देती है। एक है निष्पादन, निर्माण, जो सचमुच वहाँ विस्तार पा सकता है और पाना चाहिए जहाँ प्रतिभा प्रचुर और सुलभ है, भारत में। दूसरी है कमांड: क्या बनाना है और किस क्रम में, यह तय करना, आर्किटेक्चर और हिस्सों के बीच के इंटरफेसों का स्वामित्व, जिसे व्यवसाय अस्पष्ट रूप से चाहता है उसे एक ऐसे विनिर्देश में बदलना जो इतना सटीक हो कि बिना बातचीत के दूर बनाया जा सके, और यह आँकना कि जो लौटकर आया वह सही है या नहीं। कमांड छोटा, वरिष्ठ और महँगा है, और यह ऑनशोर रहता है, उस व्यवसाय के पास जिसकी मंशा वहन करने के लिए इसका अस्तित्व है। थीसिस यह है कि किसी ऑफशोरिंग कार्यक्रम की सफलता लगभग पूरी तरह इस बात से निर्धारित होती है कि यह कमांड परत मौजूद है और अच्छी है या नहीं, और शायद ही कभी ऑफशोर टीम की कच्ची क्षमता से, जो आमतौर पर ठीक ही होती है; और यह कि कंपनियाँ कमांड में कम-निवेश करके विफल होती हैं, ठीक इसलिए क्योंकि कमांड वही महँगा, ऑनशोर हिस्सा है जिसे ऑफशोरिंग को समाप्त कर देना था।

योगदान एक तर्क और एक छोटा मॉडल है, कोई बेंचमार्क नहीं। खंड 2 इस दावे को ऑफशोरिंग और वैश्विक सॉफ्टवेयर इंजीनियरिंग के रिकॉर्ड के सामने रखता है। खंड 3 वास्तविक विफलता का निदान करता है, केवल निष्पादन के बजाय ज़िम्मेदारी को ऑफशोर करना। खंड 4 कमांड सेंटर और उसके स्वामित्व का वर्णन करता है। खंड 5 इसका एक मॉडल देता है कि कमांड और वितरण के बीच की रेखा कहाँ गिरनी चाहिए, जो संदर्भ-भार और विनिर्देश-पूर्णता पर निर्भर करती है। खंड 6 घड़ी का उपचार करता है, और यह कि कैसे फॉलो-द-सन विलंब के बजाय लाभ का साधन बन जाता है। खंड 7 इष्टतम कमांड अनुपात निकालता है। खंड 8 एक रचित प्रकरण का अनुसरण करता है; खंड 9 से 12 परिणाम निकालते हैं, आपत्तियों का उत्तर देते हैं, सीमाएँ बताते हैं और निष्कर्ष देते हैं। पूरे दौरान प्रश्न यह है: किसी कंपनी को घर पर क्या रखना चाहिए, और उसका कितना, ताकि जो काम वह भारत भेजती है वह सही लौटकर आए?

2. पृष्ठभूमि

2.1 ऑफशोरिंग का रिकॉर्ड

IT के आउटसोर्सिंग और ऑफशोरिंग का सूचना प्रणालियों में एक बड़ा अनुभवजन्य साहित्य है, और उसका फैसला यह नहीं है कि ऑफशोरिंग से लाभ नहीं होता बल्कि यह कि उसका प्रतिफल इस पर निर्भर है कि उसे कैसे प्रबंधित किया जाता है। लैसिटी, ख़ान और विलकॉक्स (2009), दो दशकों के अध्ययनों की समीक्षा करते हुए, पाते हैं कि अकेले वेतन-अंतर के बजाय ग्राहक और आपूर्तिकर्ता की क्षमताएँ, अनुबंध की रूपरेखा और संबंध-प्रबंधन सफल और विफल अनुबंधों के बीच के फैलाव को समझाते हैं। कार्मेल और टिजा (2005) ने वैश्विक कार्यबल को सोर्सिंग का व्यवसायी-विवरण दिया और उन तरीकों को सूचीबद्ध किया जिनसे दूरी मध्यस्थता को क्षीण करती है; सहाय, निकोलसन और कृष्ण (2003) ने भारत की सीमा के पार सॉफ्टवेयर विकास का पुस्तक-लंबाई विवरण दिया, और ओशरी, कोटलार्स्की और विलकॉक्स (2007) ने यह पता लगाया कि कैसे एक अग्रणी भारतीय विक्रेता ने बिखरी हुई विशेषज्ञता के इर्द-गिर्द एक वैश्विक वितरण मॉडल को संगठित किया। रॉटमैन और लैसिटी (2006) ने सिद्ध प्रथाओं को संक्षेपित किया और पाया कि जो कंपनियाँ सफल हुईं उन्होंने विनिर्देशन, समन्वय और शासन के ऑनशोर कार्य में भारी निवेश किया, ठीक वही कार्य जिसे यह पत्र कमांड कहता है। लगातार मिलने वाला निष्कर्ष यह है कि बचत सकल है, निवल नहीं, और दोनों के बीच जो खड़ा है वह प्रबंधन-प्रयास है जो बड़े पैमाने पर घर पर ही रहता है।

2.2 दूरी महँगी क्यों है

एक दूसरा साहित्य, वैश्विक रूप से वितरित सॉफ्टवेयर विकास पर, इस क्रियाविधि को समझाता है। हर्ब्सलेब और मोकस (2003) ने, इस पत्र के सबसे केंद्रीय अध्ययन में, अनुभवजन्य रूप से दिखाया कि जिन कार्य-मदों के लिए कई स्थलों पर लोगों की आवश्यकता होती थी उन्हें पूरा होने में तुलनीय एकल-स्थल मदों की तुलना में काफ़ी अधिक समय लगता था, और इस विलंब को उस संचार की लागत और विलंबता तक पहुँचाया जिसकी स्थलों के पार समन्वय के लिए आवश्यकता होती है। रामासुब्बु और बालन (2007) ने, भारत और संयुक्त राज्य अमेरिका के बीच बिखरी परियोजनाओं का अध्ययन करते हुए, उसी दंड को सीधे परियोजना-प्रदर्शन में मापा। ओल्सन और ओल्सन (2000) ने ‘दूरी मायने रखती है’ शीर्षक के अंतर्गत सामान्य परिणाम दिया: सह-स्थित कार्य को तीव्र, समृद्ध, अनौपचारिक संचार का लाभ मिलता है जिसे वितरित कार्य खो देता है, और कोई भी उपकरण उसे पूरी तरह बहाल नहीं करता। क्रॉट और स्ट्रीटर (1995) पहले ही दिखा चुके थे कि सॉफ्टवेयर विकास का कितना हिस्सा कोडिंग के बजाय समन्वय है, और ब्रूक्स (1975) ने बहुत पहले ही यह कारण दे दिया था कि वितरित कार्य में लोग जोड़ना उसे धीमा क्यों कर सकता है: संचार-पथ लोगों की तुलना में तेज़ी से बढ़ते हैं। सबक यह नहीं है कि वितरित विकास काम नहीं कर सकता बल्कि यह कि किसी काम के हिस्से को जो भी सीमा पार करनी होती है उसकी एक कीमत होती है, और वह कीमत समय और दोषों में चुकाई जाती है।

2.3 कॉनवे का नियम और सीमा का आर्किटेक्चर

सबसे गहरा विचार जिस पर यह पत्र टिका है, वह कॉनवे का (1968) है: किसी प्रणाली की संरचना अंततः उस संगठन की संचार-संरचना का प्रतिबिंब बन जाती है जो उसे बनाता है। ऑफशोरिंग के लिए इसका उपसिद्धांत सटीक और कम-प्रयुक्त है। यदि ऑफशोर और ऑनशोर दो शिथिल रूप से संवाद करने वाले समूह हैं, तो सॉफ्टवेयर तब सबसे स्वच्छ होगा जब उनके बीच की सीमा किसी वास्तविक आर्किटेक्चरल जोड़ के साथ गिरे, एक परिभाषित इंटरफेस वाला मॉड्यूल, और तब सबसे अधिक परेशान होगा जहाँ कसकर जुड़े हुए काम के एक अकेले ढेर को अंतराल के पार बाँट दिया जाए। हर्ब्सलेब और ग्रिंटर (1999) ने इसकी सीधे पुष्टि की, यह पाते हुए कि वितरित विकास तब सफल होता है जब आर्किटेक्चर इतना मॉड्यूलर हो कि प्रत्येक स्थल एक हिस्से का स्वामी हो और हिस्सों के बीच के इंटरफेस स्पष्ट हों, और तब संघर्ष करता है जब ऐसा नहीं होता। पार्नास (1972) ने वह डिज़ाइन-अनुशासन दिया, सूचना-छिपाव, जो ऐसे मॉड्यूलों को संभव बनाता है। व्यावहारिक परिणाम, जिसे खंड 4 में विकसित किया गया है, यह है कि आर्किटेक्चर का स्वामित्व कमांड सेंटर के अनेक कार्यों में से एक कार्य नहीं है; यह वह कार्य है जो बाकी सबको संभव बनाता है, क्योंकि यह तय करता है कि महँगी सीमा कहाँ गिरती है।

3. वास्तविक विफलता: ज़िम्मेदारी को ऑफशोर करना

विशिष्ट ऑफशोरिंग विफलता धीमी टाइपिंग नहीं है; यह ऐसा काम है जो आत्मविश्वास से पूरा किया गया और चुपचाप गलत है। एक आवश्यकता सौंपी जाती है जो भेजने वाले के दिमाग़ में पूर्ण और कागज़ पर अस्पष्ट है, क्योंकि भेजने वाला व्यवसाय के साथ एक ऐसा संदर्भ साझा करता है जो प्राप्तकर्ता के पास नहीं है। ऑफशोर इंजीनियर, सक्षम और इच्छुक, अस्पष्टता का समाधान एकमात्र उपलब्ध तरीके से करता है जो बारह समय-क्षेत्रों की दूरी से संभव है: उचित रूप से अनुमान लगाकर, और बनाकर। अनुमान के गलत होने का पता स्वीकृति के समय चलता है, यदि स्वीकृति हो, या उत्पादन में, यदि न हो, और सुधार अंतराल को दो बार पार करता है, एक बार समझाने के लिए और एक बार सत्यापित करने के लिए, प्रत्येक पार करना घड़ी के कारण खोया हुआ एक दिन। इसे किसी वास्तविक प्रणाली की हर अस्पष्टता से गुणा कीजिए और मध्यस्थता समाप्त हो जाती है, इसलिए नहीं कि किसी ने कुछ अक्षम किया, बल्कि इसलिए कि जिन निर्णयों के लिए संदर्भ की आवश्यकता थी वे वहाँ लिए गए जहाँ कोई संदर्भ नहीं था।

इस पत्र की भाषा में, जो हुआ है वह यह है कि कंपनी ने ज़िम्मेदारी को ऑफशोर कर दिया जबकि उसका अभिप्राय केवल निष्पादन को ऑफशोर करने का था। सॉफ्टवेयर के किसी हिस्से की ज़िम्मेदारी उसकी अस्पष्टताओं को सही ढंग से हल करने का संचित अधिकार है: यह जानना कि व्यवसाय का क्या अभिप्राय था, यह तय करना कि हिस्सा समूचे की कैसे सेवा करता है, यह कहना कि ‘सही’ क्या है। वह अधिकार संदर्भ से अविभाज्य है, और संदर्भ स्थानीय है। निष्पादन, किसी चीज़ की अस्पष्टताएँ हल हो जाने के बाद उसका निर्माण, संदर्भ-बद्ध नहीं है और अच्छी तरह यात्रा करता है। गलती दोनों को एक ही पार्सल मानकर एक साथ भेज देना है; उपचार उन्हें अलग करना है, ज़िम्मेदारी को ऑनशोर रखना है जहाँ उसका संदर्भ बसता है, और ऑफशोर केवल निष्पादन भेजना है, जिसकी अस्पष्टताएँ पहले ही विनिर्देश में हल हो चुकी हों। जो कुछ भी आगे आता है वह इस बात का विस्तार है कि इस विभाजन को कैसे और कहाँ किया जाए।

4. कमांड सेंटर

ऑनशोर कमांड सेंटर उस ज़िम्मेदारी का संगठनात्मक घर है जिसे यात्रा नहीं करनी चाहिए। यह जानबूझकर छोटा और जानबूझकर वरिष्ठ है, क्योंकि इसका लाभ उत्पादन की मात्रा के बजाय कुछ निर्णयों की गुणवत्ता से आता है, और यह व्यवसाय के पास बैठता है, कीबोर्ड के पास नहीं। चित्र 1 मॉडल को आरेखित करता है और सारणी 3 श्रम को विभाजित करती है। कमांड सेंटर पाँच चीज़ों का स्वामी है, और मॉडल का अनुशासन यह है कि यह पाँचों का स्वामी है और कोशिश करता है कि और किसी चीज़ का स्वामी न हो।

मंशा से विनिर्देश तक। कमांड सेंटर का पहला उत्पाद सॉफ्टवेयर नहीं बल्कि विनिर्देश है: जिसे व्यवसाय अस्पष्ट रूप से चाहता है उसका एक ऐसे विवरण में अनुवाद जो इतना सटीक हो कि उस व्यक्ति द्वारा बनाया जा सके जो झुककर पूछ नहीं सकता। यह वह कार्य है जो अस्पष्टता को वहाँ हल करता है जहाँ संदर्भ है, ताकि कुछ भी वहाँ हल न करना पड़े जहाँ वह नहीं है, और यह समूचे मॉडल में अकेली सबसे अधिक लाभ देने वाली गतिविधि है, क्योंकि विनिर्देश में छोड़ी गई हर अस्पष्टता का भुगतान बाद में अंतराल के पार एक पूरे आने-जाने की पूरी कीमत पर किया जाता है।

आर्किटेक्चर और इंटरफेस। कॉनवे के नियम के अनुसार सॉफ्टवेयर संगठन के संचार-जोड़ों के साथ टूटेगा, इसलिए कमांड सेंटर आर्किटेक्चर का स्वामी ठीक इसलिए है ताकि यह चुन सके कि वे जोड़ कहाँ गिरें: यह प्रणाली को स्पष्ट इंटरफेस वाले मॉड्यूलों में विघटित करता है ताकि प्रत्येक ऑफशोर पॉड एक ऐसे हिस्से का स्वामी हो जिसे वह थोड़ी-सी सीमा-पार निर्भरताओं के साथ बना सके। सीमा को भली-भाँति खींचना ही वह चीज़ है जो दूरी को हर अंतःक्रिया पर चुकाए जाने वाले कर से बदलकर केवल कुछ सुपरिभाषित इंटरफेसों पर चुकाए जाने वाले कर में बदल देती है।

प्राथमिकता-निर्धारण। पहले क्या बनाया जाए यह एक व्यावसायिक निर्णय है, वितरण का नहीं, और यह कमांड सेंटर के पास रहता है, जो एकल बैकलॉग और उसका क्रम थामे रखता है। प्राथमिकता-निर्धारण को ऑफशोर टीम में, या एक साथ कई हितधारकों में बिखेरना अंतराल के पार ठीक उसी समन्वय को फिर से ले आता है जिसे रोकने के लिए मॉडल का अस्तित्व है।

स्वीकृति और गुणवत्ता-द्वार। कमांड सेंटर तय करता है कि ‘पूर्ण’ क्या है और लौटाए गए काम को उसके विरुद्ध परखता है, एक ऐसा द्वार थामे रखते हुए जिस पर व्यवसाय भरोसा करता है। यह विनिर्देश का प्रतिरूप है: पहले से सही-पन को परिभाषित करके, यह लौटने पर उसका सत्यापन करता है, और चूँकि यह ऑनशोर है और व्यवसाय के निकट है, यह केवल कार्य नहीं बल्कि उपयुक्तता को आँक सकता है।

एक जवाबदेह स्वामी। अंततः कमांड सेंटर वह स्थान है जहाँ जवाबदेही अविभाजित है: एक अकेला स्वामी जो वितरित की गई चीज़ के लिए व्यवसाय के प्रति जवाबदेह है, जो अंतराल के पार उँगली नहीं उठा सकता। जो जवाबदेही सीमा के पार बँटी हुई है वह जवाबदेही है जो ग़ायब हो चुकी है, और उसे एक ऑनशोर बिंदु पर बहाल करना ही बहुत हद तक वह चीज़ है जो मॉडल को शासनीय बनाती है।

5. रेखा खींचना

यदि कमांड ऑनशोर रहता है और निष्पादन ऑफशोर जाता है, तो सब कुछ इस पर निर्भर करता है कि उनके बीच की रेखा कहाँ खींची जाती है, कार्य-दर-कार्य। जो मॉडल इस चुनाव को नियंत्रित करता है उसके दो अक्ष हैं। पहला किसी कार्य का संदर्भ-भार है: उसे सही ढंग से हल करने के लिए कितने स्थानीय, मौन, व्यवसाय-विशिष्ट ज्ञान की आवश्यकता है, किसी ऐसे परिवर्तन के लिए ऊँचा जो किसी सूक्ष्म नियामक नियम या किसी दीर्घकालिक ग्राहक प्रतिबद्धता को छूता है, और किसी स्पष्ट अनुबंध वाले सुपरिभाषित घटक के लिए नीचा। दूसरा वह विनिर्देश-पूर्णता है जो कमांड सेंटर उसे दे सकता है: उसकी अस्पष्टताओं को पहले से, कागज़ पर, बिना बातचीत के कितनी पूरी तरह हल किया जा सकता है। किसी कार्य को ऑफशोर करना तब सुरक्षित है जब जो अवशिष्ट अस्पष्टता ऑफशोर पॉड तक पहुँचती है, उसका संदर्भ-भार उस पर लागू विनिर्देश-पूर्णता के निवल, छोटी हो। संदर्भ-भार के लिए $\kappa$ और विनिर्देश-पूर्णता के लिए $s$ लिखते हुए, दोनों एक समान पैमाने पर, अवशिष्ट है

और यह $\alpha$ है, काम की कच्ची कठिनाई नहीं, जो पुनः-कार्य की भविष्यवाणी करती है। मॉडल का एक तीखा प्रबंधकीय पाठ है, जो सारणी 1 में आरेखित है। एक निम्न-संदर्भ कार्य अपनी तकनीकी कठिनाई चाहे जो हो, स्वच्छ रूप से ऑफशोर होता है। एक उच्च-संदर्भ कार्य ऑफशोरिंग के लिए अनुपयुक्त नहीं है; यह अविनिर्दिष्ट ऑफशोरिंग के लिए अनुपयुक्त है, और कमांड सेंटर का काम $s$ को तब तक बढ़ाना है जब तक $\alpha$ भेजने लायक छोटा न हो जाए। जहाँ संदर्भ-भार सचमुच अपरिवर्तनीय है, जहाँ ज्ञान को बिल्कुल भी लिखा नहीं जा सकता, वहाँ कार्य ऑनशोर रहता है, और इसे ईमानदारी से पहचानना अनुशासन का हिस्सा है। जिस विफलता-रूप को मॉडल नाम देता है वह निम्न-पूर्णता विनिर्देश के साथ भेजा गया उच्च-संदर्भ कार्य है: अधिकतम अवशिष्ट अस्पष्टता, अधिकतम दूरी पर, अनुमान से ऑफशोर हल की गई।

6. घड़ी

किसी पश्चिमी व्यवसाय और भारत के बीच का समय-अंतर, कोई नौ से बारह घंटे, वह विशेषता है जिसे व्यवसायी सबसे अधिक बार एक शुद्ध देयता मानते हैं और जिसे कमांड सेंटर सबसे स्वच्छ रूप से एक परिसंपत्ति में बदल सकता है। बिना देखभाल के, यह अंतराल विलंबता है: ऑफशोर दिन के अंत में पूछा गया प्रश्न ऑनशोर दिन के अंत में उत्तरित होता है, और एक अकेला स्पष्टीकरण अपनी सामग्री चाहे जो हो एक कैलेंडर-दिन की लागत लेता है, इसलिए स्पष्टीकरणों की एक शृंखला वास्तविक सामग्री के एक घंटे को हल करने में एक सप्ताह की लागत लेती है। यही वह क्रियाविधि है जिससे बुरी तरह चलाई गई ऑफशोरिंग धीमी महसूस होती है, तब भी जब हर कोई कठिन परिश्रम करता है: महत्वपूर्ण पथ अंतराल से होकर गुज़रता है, और अंतराल प्रति पार करने पर एक दिन जोड़ता है।

अच्छी तरह चलाई जाए, तो वही अंतराल एक दूसरी पाली है। यदि कमांड सेंटर ऐसा काम सौंपता है जिसकी अस्पष्टताएँ पहले ही हल हो चुकी हैं, तो ऑफशोर पॉड्स ऑनशोर रात भर निष्पादन करते हैं और ऑनशोर सुबह तक परिणाम लौटा देते हैं, और जिस दिन व्यवसाय सोता रहता है वह प्रतीक्षा के दिन के बजाय प्रगति का दिन होता है। दोनों परिणामों के बीच का अंतर पूरी तरह इस बात पर है कि जो सौंपा जाता है उसकी अवशिष्ट अस्पष्टता $\alpha$ क्या है: $\alpha \approx 0$ वाले हस्तांतरण को किसी आने-जाने की आवश्यकता नहीं और घड़ी शुद्ध लाभ है; अनसुलझे प्रश्नों से भरे हस्तांतरण में घड़ी आपके विरुद्ध हो जाती है, क्योंकि हर प्रश्न एक पूरा दिन है। इसे देखने का एक कच्चा तरीका यह है कि दूसरी पाली से प्रभावी गति-वृद्धि है

जहाँ $\eta$ यह मापता है कि काम को कितनी स्वच्छ रूप से सौंपा जा सकता है और $\alpha$ समीकरण (1) की अवशिष्ट अस्पष्टता है; ज्यों-ज्यों $\alpha\to 0$ होता है घड़ी एक वास्तविक अतिरिक्त पाली के निकट पहुँचती है, और ज्यों-ज्यों $\alpha$ बढ़ती है लाभ ढह जाता है और फिर उलटकर प्रति-प्रश्न-एक-दिन वाले कर में बदल जाता है। कमांड सेंटर घड़ी को उस विनिर्देश और पूर्ण की परिभाषा का स्वामी बनकर कमाता है जो $\alpha$ को छोटा बनाते हैं, यही कारण है कि फॉलो-द-सन अच्छी कमांड का परिणाम है, कोई शेड्यूलिंग चाल नहीं जिसे अलग से ख़रीदा जा सके।

7. कमांड अनुपात

कितनी कमांड पर्याप्त है? इस प्रश्न का एक वास्तविक उत्तर है, और वह न तो ‘जितनी कम संभव हो’ है, वह सहज बुद्धि जो दीवार-के-पार-फेंक-दो ऑफशोरिंग पैदा करती है, और न ही ‘जितनी अधिक संभव हो’ है, जो ऑनशोर वही लागत फिर से खड़ी कर देती है जिसे ऑफशोरिंग को बहाना था। मान लीजिए $r$ कमांड अनुपात है, जो ऑनशोर कमांड सेंटर की क्षमता को उस ऑफशोर वितरण क्षमता के अंश के रूप में दर्शाता है जिसे वह शासित करता है। कमांड की लागत ऊँची ऑनशोर दर $w_c$ प्रति इकाई है; वितरण की लागत निम्न ऑफशोर दर $w_o$ प्रति इकाई है। कमांड का मूल्य यह है कि यह पॉड्स तक पहुँचने वाली अवशिष्ट अस्पष्टता को और इस तरह उनके द्वारा किए जाने वाले पुनः-कार्य को कम करता है: अधिक कमांड का अर्थ है अंतराल पार करने से पहले और बाद में अधिक काम का विनिर्देशन, समीक्षा और द्वार-जाँच, और इस तरह वितरित काम पर एक निम्न पुनः-कार्य गुणक। उस गुणक का एक उपयोगी रूप है

जहाँ $a$ उस पुनः-कार्य को मापता है जो बिल्कुल भी कमांड न होने पर लगता, जो काम की अंतर्निहित अस्पष्टता से निर्धारित होता है, और $b$ यह मापता है कि कमांड कितने प्रभावी ढंग से हल की गई अस्पष्टता में बदलती है। तैयार काम की एक इकाई को वितरित करने की कुल लागत, कमांड जमा पुनः-किया गया वितरण, तब है

एक बढ़ते पद, कमांड की लागत, और एक घटते पद, उस पुनः-कार्य जिसे कमांड रोकती है, का योग, इसलिए इसका एक अकेला आंतरिक न्यूनतम है। $C'(r)=0$ रखने पर लागत-न्यूनतम करने वाला कमांड अनुपात मिलता है

जो इस पत्र का केंद्रीय मात्रात्मक परिणाम है। यह तीन बातें कहता है जिन पर एक प्रबंधक कार्य कर सकता है। कमांड की इष्टतम मात्रा धनात्मक है: $r^\ast > 0$ जब भी $w_o a b > w_c$, अर्थात जब भी कमांड कुछ भी प्रभावी हो और अस्पष्टता कुछ भी वास्तविक हो, इसलिए काम को दीवार के पार फेंकना ($r = 0$) कभी इष्टतम नहीं होता। यह परिमित है: $r^\ast$ से आगे की कमांड उस पुनः-कार्य से अधिक लागत लेती है जितनी वह बचाती है, इसलिए सब कुछ ऑनशोर रखना भी इष्टतम नहीं है। और यह सही दिशा में चलता है: $r^\ast$ काम की अस्पष्टता ($a$) और इस बात के साथ बढ़ता है कि कमांड उसे कितनी अच्छी तरह हल करती है ($b$), और ज्यों-ज्यों ऑनशोर कमांड ऑफशोर वितरण के सापेक्ष महँगी होती है ($w_c/w_o$) घटता है, इसलिए अस्पष्ट, उच्च-संदर्भ पोर्टफोलियो एक मोटी कमांड परत के योग्य हैं और सरल, सुपरिभाषित पोर्टफोलियो एक पतली परत के। चित्र 2 $C(r)$ और इष्टतम के दोनों ओर की दो विफलता-व्यवस्थाओं को आरेखित करता है।

8. एक रचित प्रकरण

यह प्रकरण रचित है, प्रेक्षित नहीं: इसके आँकड़े उदाहरणात्मक और आंतरिक रूप से संगत हैं, और इसका उद्देश्य किसी परिणाम की रिपोर्ट करना नहीं बल्कि मॉडल की मात्राओं को प्रशंसनीय मान लेते हुए दिखाना है। एक पश्चिमी समूह अपनी बैक-ऑफिस प्रणालियों के लिए एप्लिकेशन विकास चलाता है और, तीन वर्ष पहले, उसने उसके अधिकांश को स्टाफ-संवर्धन आधार पर भारत के एक विक्रेता को ऑफशोर कर दिया: उसने मुट्ठी भर ऑनशोर परियोजना-प्रबंधक रखे, आवश्यकताएँ उसी रूप में लिखीं जैसे वह हमेशा लिखता था, और सफलता को स्थानांतरित कर्मचारी-संख्या और बचाई गई दैनिक-दर से मापा। कागज़ पर उसने एक डेवलपर की लागत आधी कर दी थी। व्यवहार में किसी फ़ीचर का सीधा-सीधा वितरण, अनुरोध से स्वीकृत उत्पादन-परिवर्तन तक, लंबा हो गया था, उत्पादन में दोष-निकासी दर बढ़ गई थी, और ऑफशोर टीम के घंटों का एक बड़ा और बढ़ता हिस्सा उन फ़ीचरों को पुनः-करने में जाता था जिन्हें किसी अस्पष्ट आवश्यकता के एक उचित किंतु गलत पाठ के अनुसार बनाया गया था। बचत सकल थी; निवल रूप में, वह पतली और गिरती हुई थी। सारणी 2 ‘पहले’ वाला स्तंभ देती है।

फिर समूह ने अनुबंध को एक कमांड सेंटर के इर्द-गिर्द पुनर्निर्मित किया। उसने न विक्रेता बदला और न काम घर लाया; उसने एक पतली, वरिष्ठ ऑनशोर परत जोड़ी, कुल कर्मचारी-संख्या का कुछ प्रतिशत, जिसने खंड 4 की पाँच चीज़ों का स्वामित्व लिया: उसने आवश्यकताओं को स्पष्ट स्वीकृति-मानदंडों वाले विनिर्देशों के रूप में फिर से लिखा, आर्किटेक्चर को फिर से काटा ताकि प्रत्येक ऑफशोर पॉड एक परिभाषित इंटरफेस के पीछे एक मॉड्यूल का स्वामी हो, एक अकेला क्रमबद्ध बैकलॉग थामा, और उत्पादन तक कुछ भी पहुँचने से पहले एक स्वीकृति-द्वार चलाया। ऑफशोर टीम और उसकी दरें अपरिवर्तित थीं; जो बदला वह उस तक पहुँचने वाली अवशिष्ट अस्पष्टता $\alpha$ थी। पुनः-कार्य घटा ज्यों-ज्यों विनिर्देशों ने उस अनुमान को हल किया जिसने उसे चलाया था, दोष-निकासी दर गिरी ज्यों-ज्यों द्वार ने उसे पकड़ा जिसे अंतराल छिपाया करता था, और घड़ी विलंबता से दूसरी पाली में बदल गई ज्यों-ज्यों हस्तांतरणों को आने-जाने की आवश्यकता रुकी। जोड़ी गई कमांड की लागत उसके द्वारा हटाए गए पुनः-कार्य का एक अंश थी, जो व्यवहार में समीकरण (5) है: अनुबंध $r^\ast$ से बहुत बाईं ओर चल रहा था, और उसकी ओर बढ़ना कुल लागत को कम करता गया, भले ही उसने ऑनशोर लागत बढ़ाई। सारणी 2 इस परिवर्तन का अनुसरण करती है।

9. संचालन मॉडल के लिए क्या बदलता है

कमांड सेंटर को अपनाना यह बदल देता है कि किसी कंपनी को किसमें अच्छा होना चाहिए, और यह बदलाव असहज है क्योंकि यह उस सहज बुद्धि के विरुद्ध चलता है जिसने ऑफशोरिंग को प्रेरित किया। बचत अब भी वास्तविक है, किंतु इसे केवल उस कमांड परत पर ऑनशोर और वरिष्ठ दरों पर ख़र्च करके ही प्राप्त किया जाता है जिसे भोला व्यावसायिक-तर्क समाप्त की जाने वाली बर्बादी मानता था। सारणी 3 मॉडल द्वारा अपेक्षित श्रम-विभाजन प्रस्तुत करती है। दुर्लभ संसाधन वे मुट्ठी भर वरिष्ठ लोग बन जाते हैं जो मंशा, आर्किटेक्चर और स्वीकृति को भली-भाँति थाम सकते हैं, और किसी कंपनी की ऑफशोरिंग क्षमता इस बात से परिबद्ध होती है कि उसके पास ऐसे कितने लोग हैं, इससे नहीं कि वह कितने ऑफशोर इंजीनियर भर्ती कर सकती है। मापदंड भी बदलता है: स्थानांतरित कर्मचारी-संख्या और बचाई गई दैनिक-दर, वे संख्याएँ जो दीवार-के-पार-फेंक-दो ऑफशोरिंग को अच्छा दिखाती हैं, फ़ीचर लीड-समय, दोष-निकासी और पुनः-कार्य में बिताए गए ऑफशोर घंटों के हिस्से से प्रतिस्थापित हो जाती हैं, वे संख्याएँ जो बताती हैं कि कमांड अपना काम कर रही है या नहीं।

वरिष्ठता कहाँ बैठती है, इसमें एक दूसरी बदलाव है। दीवार-के-पार-फेंक-दो ऑफशोरिंग प्रवृत्त होती है कि दिलचस्प, वरिष्ठ काम को बाकी सबके साथ ऑफशोर भेज दे और एक कनिष्ठ समन्वय परत घर पर रखे; कमांड-सेंटर मॉडल इसे उलट देता है, वरिष्ठता को ऑनशोर रखते हुए जहाँ संदर्भ है और ऑफशोर टीम को निष्पादन में उत्कृष्ट होने देते हुए, उससे ऐसा संदर्भ आपूर्ति करने को कहे बिना जो उसके पास हो ही नहीं सकता। इसे अक्सर ऑफशोर टीम के प्रति अविश्वास के रूप में ग़लत पढ़ा जाता है। यह इसके विपरीत है: यह वह व्यवस्था है जो एक सक्षम ऑफशोर टीम को अपना सर्वोत्तम काम करने देती है, उससे ऐसी अस्पष्टताएँ हल करने को न कहकर जिन्हें उसकी दूरी पर कोई भी भली-भाँति हल नहीं कर सकता, और उसे इतने स्पष्ट विनिर्देश देकर कि उसकी योग्यता अनुमान लगाने के बजाय निर्माण पर ख़र्च हो।

10. आपत्तियाँ और उत्तर

कमांड सेंटर केवल ऑनशोर लागत जोड़ता है और बचत को क्षीण करता है। यह ऑनशोर लागत जोड़ता है और निवल बचत को बढ़ाता है, जो समीकरण (5) का समूचा मर्म है: अधिकांश विफल होते अनुबंध $r^\ast$ से बहुत बाईं ओर बैठते हैं, जहाँ थोड़ी अधिक कमांड अपनी लागत से कहीं अधिक पुनः-कार्य हटा देती है। कमांड सेंटर बचत पर ऊपरी-व्यय नहीं है; यह वह क्रियाविधि है जो एक सकल बचत को निवल बचत में बदल देती है। जो कंपनी सचमुच पहले से ही $r^\ast$ पर है उसे कमांड नहीं जोड़नी चाहिए; लगभग कोई भी नहीं है।

यदि आपको सब कुछ इतनी सटीकता से विनिर्दिष्ट ही करना है, तो उसे ऑनशोर ही क्यों न बना लें? क्योंकि विनिर्देश और निर्माण की लागतें बहुत भिन्न हैं और उनकी दुर्लभताएँ बहुत भिन्न हैं। विनिर्देश वरिष्ठ, संदर्भ-बद्ध काम की एक छोटी मात्रा है; निर्माण ऐसे काम की एक बड़ी मात्रा है जो विनिर्दिष्ट हो जाने पर संदर्भ-बद्ध नहीं रहता। मॉडल उस बड़ी, सस्ते-में-कहीं-भी-रखी-जा-सकने वाली मात्रा को वहाँ भेजता है जहाँ वह सुलभ है और केवल छोटी, संदर्भ-बद्ध मात्रा को घर पर रखता है। दोनों को फिर एक साथ ढहा देना ठीक उसी मध्यस्थता को छोड़ देना है जो वास्तविक है।

आधुनिक उपकरण और वीडियो कॉल ने दूरी को अप्रासंगिक बना दिया है। उन्होंने उसे छोटा किया है, अप्रासंगिक नहीं, और यह प्रमाण कि दूरी अब भी मायने रखती है सुदृढ़ है (ओल्सन और ओल्सन, 2000; हर्ब्सलेब और मोकस, 2003)। उपकरण एक पार करने की लागत कम करते हैं; वे न उस दिन को हटाते हैं जो घड़ी एक आने-जाने में जोड़ती है, न उस अनौपचारिक, परिवेशगत संचार को बहाल करते हैं जिससे सह-स्थित टीमें बिना ध्यान दिए अस्पष्टता हल करती हैं। कमांड सेंटर वह संरचनात्मक उत्तर है जिसका उपकरण पूरक हैं किंतु प्रतिस्थापन नहीं।

हमारा ऑफशोर साझेदार बहुत सक्षम है और पूरी चीज़ का स्वामी हो सकता है। क्षमता मुद्दा नहीं है; संदर्भ है। एक अत्यधिक सक्षम ऑफशोर टीम भी ऐसी अस्पष्टता हल नहीं कर सकती जिसके समाधान के लिए यह जानना आवश्यक हो कि व्यवसाय का क्या अभिप्राय था, और उससे ऐसा करने को कहना उसकी योग्यता को एक ऐसी समस्या के विरुद्ध खड़ा कर देता है जिसे दूरी अघुलनशील बना देती है। मॉडल ज़िम्मेदारी को ऑनशोर इसलिए नहीं रखता कि ऑफशोर टीम कमज़ोर है बल्कि इसलिए कि ज़िम्मेदारी एक ऐसे संदर्भ से बँधी है जो ऑनशोर है।

11. सीमाएँ

यह एक व्यवसायी-उन्मुख तर्क है जिसका मॉडल जानबूझकर सरल है, और इसकी सीमाएँ स्पष्ट होनी चाहिए। खंड 5 से 7 का मॉडल उदाहरणात्मक है: समीकरण (1) का अवशिष्ट-अस्पष्टता रूप, समीकरण (3) का घातांकीय पुनः-कार्य गुणक और समीकरण (5) का एकल इष्टतम अनुपात सुपाठ्यता के लिए चुने गए सरलीकरण हैं, और स्थिरांक $a$, $b$, $w_c$ और $w_o$ यहाँ मापे नहीं गए हैं; एक कंपनी उन्हें अपने स्वयं के पुनः-कार्य और दर-आँकड़ों से आकलित कर सकती है, और हम यह अपेक्षा करेंगे कि गुणात्मक आकृति, एक आंतरिक इष्टतम जो अस्पष्टता और सापेक्ष लागत के साथ चलता है, वहाँ भी बनी रहे जहाँ सटीक रूप न बने। तर्क उस काम तक सीमित है जिसकी अस्पष्टताएँ, प्रयास से, विनिर्देश में हल की जा सकती हैं; सचमुच अनुसंधान-जैसा काम, जहाँ अभी तक कोई नहीं जानता कि सही क्या है, मॉडल में बुरी तरह बैठता है और अधिकांशतः सह-स्थित रहना चाहिए। यह पत्र भारत पर आधारित है क्योंकि वहीं आपूर्ति की गहराई और अभ्यास का पैमाना है, किंतु मॉडल में कुछ भी किसी देश के लिए विशिष्ट नहीं है; यह किसी वास्तविक दूरी और घड़ी के पार किसी भी ऑनशोर–ऑफशोर विभाजन पर लागू होता है। और मॉडल यह मानता है कि कंपनी एक वरिष्ठ कमांड परत को बिल्कुल भी नियुक्त करने में सक्षम है; जो कंपनी ऐसा नहीं कर सकती उसे ईमानदार होना चाहिए कि वह अभी तक भली-भाँति ऑफशोर करने में सक्षम नहीं है, बजाय इसके कि बुरी तरह ऑफशोर करे और परिणाम को भारत पर एक फैसला कहे।

12. निष्कर्ष

भारत को IT कार्य ऑफशोर करना उन कंपनियों को निराश करता है जो गलत चीज़ को ऑफशोर करती हैं: वे निष्पादन के साथ-साथ ज़िम्मेदारी को भी भेज देती हैं, और इस तरह काम को उस संदर्भ और विवेक से काट देती हैं जो उसे सही बनाते हैं, और फिर देखती हैं कि पुनः-कार्य और घड़ी उस बचत को निगल जाते हैं जिसके लिए वे आई थीं। उपचार काम को घर लाना नहीं बल्कि उसे सही ढंग से विभाजित करना है, उस पतली, वरिष्ठ कमांड को ऑनशोर रखते हुए जिसे व्यवसाय के पास रहना चाहिए, क्या बनाना है यह तय करना, आर्किटेक्चर और इंटरफेसों का स्वामित्व, मंशा को विनिर्देश में बदलना, और स्वीकृति थामना, जबकि निष्पादन भारत में विस्तार पाता है जहाँ प्रतिभा प्रचुर और सुलभ है। रेखा कहाँ खींची जाए यह एक प्रश्न है जिसका उत्तर किसी कार्य की अवशिष्ट अस्पष्टता देती है, और कमांड सेंटर का कौशल विनिर्देश को तब तक बढ़ाना है जब तक वह अस्पष्टता अंतराल पार करने लायक छोटी न हो जाए; कितनी कमांड रखी जाए यह एक ऐसा प्रश्न है जिसका एक वास्तविक इष्टतम है, धनात्मक और परिमित, जो काम की अस्पष्टता के साथ बढ़ता है और ज्यों-ज्यों कमांड महँगी होती है घटता है। इस तरह किए जाने पर दूरी एक कर नहीं रह जाती और बारह-घंटे की घड़ी एक दूसरी पाली बन जाती है, और वह मध्यस्थता जो हमेशा वास्तविक थी अंततः बनी रहती है। निर्माण को ऑफशोर करें; उसे घर से कमांड करें। जो कंपनी याद रखती है कि दोनों में से कौन संदर्भ से बँधा है, और कौन नहीं, वह भारत को ऑफशोरिंग में महारत हासिल कर सकती है; जो कंपनी भूल जाती है वह गलत ढंग से यह निष्कर्ष निकालती रहेगी कि समस्या रेखा का दूसरा छोर थी।

Appendix A. कमांड सेंटर खड़ा करना

नीचे दी गई प्रथाएँ वही हैं जो खंड 4 के विभाजन को व्यवहार में टिकाए रखती हैं। कोई भी नई नहीं है; अनुशासन ही मूल्य है।

संदर्भ

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.