Org रणनीति लैंडस्केप का फ़ैसला है

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 5 (कुल 6 में से) — अध्याय एंटरप्राइज़ डेटा को समझना, Data Architect कोर्स का अध्याय 4। हर मॉड्यूल अपने आप में पूरा है। पिछला: सिस्टम लैंडस्केप बनाएँ · अगला: Steve Trucking का लैंडस्केप

यह मॉड्यूल किस सवाल का जवाब देता है: एक org या कई, और वह कहाँ चलता है?

जब मैं CTA उम्मीदवारों को पढ़ाता हूँ, तो उनसे कहता हूँ कि किसी परिदृश्य का सबसे बड़ा फ़ैसला पहले पाँच या दस मिनट में आता है: हम कितने Salesforce orgs से निपट रहे हैं? एक बड़ा org? North America, EMEA और APAC के लिए क्षेत्रीय orgs? अलग-अलग बिज़नेस यूनिट के लिए अलग orgs? अपने नियमों वाले किसी देश के लिए एक खास org? और इससे सीधे जुड़ा सवाल: वे orgs कहाँ चलते हैं?

ये एडमिन की बारीकियाँ नहीं हैं। ये बदल देते हैं कि डेटा कहाँ रहता है, इंटीग्रेशन, रिपोर्टिंग, identity, और दुनिया भर के लोग सिस्टम तक कैसे पहुँचते हैं। इसीलिए मैं org रणनीति को लैंडस्केप का फ़ैसला मानता हूँ, और इसीलिए इसे सबसे पहले लेता हूँ।

एक org से शुरू करें

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

इसलिए मैं इसलिए org नहीं जोड़ता कि यूरोप चीज़ें थोड़ी अलग तरह करता है, या किसी डिवीज़न की अपनी सेल्स प्रोसेस है, या बिज़नेस यूनिट एक-दूसरे को पसंद नहीं करतीं। ये ज़रूरतें हैं, org की सीमाएँ नहीं। सवाल यह है: कौन-सी ताकत इतनी मज़बूत है कि दूसरे org को जायज़ ठहराए?

कई orgs की एक कीमत होती है

एक org को तीन में बाँट दें (North America, Europe, Asia-Pacific), और आपने तीन साफ़-सुथरे बॉक्स नहीं बनाए; आपने नए सवाल खड़े कर दिए। एक वैश्विक ग्राहक कहाँ रहता है? अगर वह दो क्षेत्रों में काम करता है तो: दो कॉपी, और मालिक कौन-सी? कोई वैश्विक रिपोर्ट कैसे बनाता है? क्या ERP तीनों से इंटीग्रेट होता है, क्या warehouse को तीन फ़ीड मिलती हैं, क्या identity provider तीनों से जुड़ता है? क्या हम एक ही functionality तीन बार डिप्लॉय करते हैं और तीन डेटा मॉडल को एक सीध में रखते हैं? अगर किसी एजेंट को किसी ग्राहक का वैश्विक नज़ारा चाहिए, तो वह किस org से पूछे?

मॉड्यूल 4 के लैंडस्केप पर वापस जाएँ। एक Salesforce बॉक्स तीन बन जाता है, और हर तीर दोबारा बनता है। मल्टी-org गलत नहीं है। लेकिन यह कभी मुफ़्त नहीं होता।

असली सीमाएँ ढूँढें

दूसरे org को क्या जायज़ ठहरा सकता है? ऐसी सीमाएँ जो इतनी असली हों कि आर्किटेक्चर को आकार दें: data residency (डेटा किस देश में रहे), नियम-क़ानून, क़ानूनी अलगाव, सच में अलग ऑपरेटिंग मॉडल, ऐसा अधिग्रहण जो अभी एक नहीं हुआ, क्षेत्रीय होस्टिंग की कोई बाधा, बहुत अलग गवर्नेंस, कभी-कभी स्केल या अलगाव। यह सूची पूरी नहीं है। मुद्दा यह है कि “ये समूह अलग हैं” और “इन समूहों को एक आर्किटेक्चरल सीमा चाहिए” में फ़र्क करें। दूसरी कसौटी कहीं ऊँची है।

भूगोल अपने-आप org रणनीति नहीं है

“हम 30 देशों में काम करते हैं, इसलिए हमें 30 orgs चाहिए।” नहीं। भूगोल तब मायने रखता है जब वह अपने साथ कोई आर्किटेक्चरल ज़रूरत लाए। एक कंपनी के यूज़र पूरी दुनिया में एक साझा आर्किटेक्चर पर हो सकते हैं। इसलिए मैं देश नहीं गिनता; मैं पूछता हूँ कि उनके साथ क्या आता है। डेटा कहाँ स्टोर किया जा सकता है? कहाँ प्रोसेस किया जा सकता है? क्या व्यक्तिगत डेटा को सीमाओं के पार ले जाने पर पाबंदियाँ हैं? residency के बारे में अनुबंध के वादे? क्या किसी क्षेत्र को अलग Salesforce सेवा या होस्ट चाहिए? “जर्मनी में एक दफ़्तर है” अपने-आप में काफ़ी नहीं है।

होस्टिंग भी डायग्राम का हिस्सा है

यहाँ आधुनिक प्लेटफ़ॉर्म लैंडस्केप को और दिलचस्प बनाता है। Hyperforce Salesforce को दुनिया भर के क्षेत्रों में पब्लिक क्लाउड इन्फ़्रास्ट्रक्चर पर चलाता है, जिससे ग्राहकों को इस पर ज़्यादा विकल्प और नियंत्रण मिलता है कि उनका डेटा कहाँ रहे (Salesforce Hyperforce: General Information and FAQ (opens in a new tab))। इसलिए जब मैं किसी बॉक्स पर “Salesforce, Europe” लिखता हूँ, तो वह जगह मायने रख सकती है।

लेकिन सटीक रहें। कोई org कहाँ रहे, यह चुनना इस बात का वादा नहीं कि हर सेवा का हर byte वहीं रहेगा। Salesforce ग्राहकों से कहता है कि वे Hyperforce के trust और compliance दस्तावेज़ देखें, जिनमें उनकी ख़रीदी सेवाओं के अतिरिक्त sub-processors भी शामिल हैं (वही स्रोत)। इसलिए यह न कहें कि “हम देश X में Hyperforce पर हैं, इसलिए सब कुछ देश X में ही रहता है।” जानें कि आप असल में कौन-सी सेवाएँ इस्तेमाल कर रहे हैं, और कौन-सी ज़रूरत पूरी कर रहे हैं। और गौर करें कि आप क्या चुनते हैं: क्षेत्र (region), उसके नीचे का क्लाउड नहीं। Hyperforce AWS पर चलता है, 2026 के अंत से Google Cloud पर भी, और कौन-सा org किस provider पर बैठेगा, यह Salesforce तय करता है; जिस ग्राहक के पास किसी एक से बचने की दस्तावेज़ी नियामक वजह हो, वह अपनी account टीम से बात करता है (वही स्रोत)।

वकील न बनें

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

जब यूरोप को अपना org मिलता है

यह एक सीमा है जो मैं असली परिदृश्यों में देखता हूँ। एक कंपनी की अमेरिका में भारी मौजूदगी है और यूरोप में भी: दो बड़े ग्राहक आधार, दो सेल्स और सर्विस ऑपरेशन, और GDPR के इर्द-गिर्द बना एक यूरोपीय प्राइवेसी प्रोग्राम। GDPR यह नहीं कहता कि “आपको एक अलग Salesforce org चाहिए।” वह व्यक्तिगत डेटा के नियम तय करता है, जिनमें यह भी शामिल है कि उसे EU से बाहर कब ट्रांसफ़र किया जा सकता है (GDPR, Chapter V (opens in a new tab))। लेकिन यह कंपनी, अपनी प्राइवेसी और लीगल टीमों के साथ मिलकर, तय करती है कि उसके यूरोपीय ग्राहकों का व्यक्तिगत डेटा यूरोप में होस्ट किए गए एक org में रहे, जिसे उसकी यूरोपीय टीम चलाए, उसके यूरोपीय गवर्नेंस के तहत। यह एक असली ज़रूरत है, और यह उनकी है, मेरी नहीं।

अब “एक बड़ा वैश्विक org” कोई पसंद नहीं रहा। लैंडस्केप पर एक सीमा है, Salesforce AMER और Salesforce EMEA, और मुझे उसे बनाना है। और दूसरा org कभी सिर्फ़ एक और बॉक्स नहीं होता।

Click to enlarge

दो orgs, AMER और EMEA। amber रंग वह है जो दूसरा org जोड़ता है: एक और बॉक्स नहीं, बल्कि हर तीर दोबारा।

तीरों पर दोबारा चलें

एक से ज़्यादा org हों, तो लैंडस्केप पर दोबारा चलें। क्या ERP हर org को प्रोडक्ट भेजता है? क्या हर एक ऑर्डर वापस भेजता है? ग्राहक कहाँ मास्टर होते हैं, और क्या उनका डेटा क्षेत्रों के पार जा सकता है? इंटीग्रेशन लेयर वैश्विक है या क्षेत्रीय? कौन-सा identity provider किन यूज़र्स को साइन इन कराता है? एनालिटिकल डेटा कहाँ जाता है?

तीन जगहें कीमत सबसे जल्दी दिखाती हैं:

रिपोर्टिंग। CEO को वैश्विक pipeline चाहिए। एक org में यह एक Salesforce रिपोर्ट है। तीन में, यह एंटरप्राइज़ रिपोर्टिंग की समस्या है: replicate करें, warehouse में भेजें, federate करें? इसे कितना ताज़ा होना चाहिए, और क्या orgs “pipeline” को एक ही तरह परिभाषित भी करते हैं? एनालिटिक्स वहीं रहता है जहाँ डेटा रहता है, और अगर आप ऑपरेशनल डेटा को जानबूझकर बाँटते हैं, तो आपको डिज़ाइन करना होगा कि समझ (insight) फिर से एक साथ कैसे आए।

मास्टर डेटा। एक वैश्विक ग्राहक अमेरिका, जर्मनी और जापान में ख़रीदता है। तीन orgs, तो शायद तीन Accounts। आपको कैसे पता चले कि वे एक ही कंपनी हैं? वैश्विक पहचानकर्ता (identifier) क्या है, और उसका मालिक कौन है? अगर एक क्षेत्र पता बदलता है, तो क्या वह बाकी जगह फैलना चाहिए? कौन-से एट्रिब्यूट वैश्विक हैं और कौन-से क्षेत्रीय? org रणनीति पहचान की समस्या हल नहीं करती; वह पहचान की समस्या को बदल देती है। वह अध्याय 6 है।

इंटीग्रेशन। एक org: Salesforce, इंटीग्रेशन लेयर, ERP। तीन orgs: इंटीग्रेशन लेयर में तीन कनेक्शन, शायद एक का अपना होस्ट और कनेक्टिविटी, कुछ flow साझा, कुछ क्षेत्रीय, कुछ डेटा को पार जाने की इजाज़त और कुछ को नहीं। नेटवर्क भी बदल सकता है: अगर एंटरप्राइज़ को Hyperforce तक समर्पित निजी कनेक्टिविटी चाहिए (AWS पर, Salesforce AWS Direct Connect की सलाह देता है; वही Hyperforce FAQ), तो डायग्राम पर हर org और होस्ट योजना बनाने लायक एक और कनेक्शन है। कोई org कहाँ चलता है, इससे यह बदल सकता है कि बाकी एंटरप्राइज़ उस तक कैसे पहुँचता है।

एक org या कई, यह फ़ैसला आप अभी लेते हैं, शुरुआत में, लैंडस्केप पर। उसके बाद orgs आपस में डेटा कैसे साझा करते हैं (cross-org Salesforce Connect, उनके बीच इंटीग्रेशन, Data 360), यह कार्यप्रणाली है, और अध्याय 14, एक org या कई? (coming soon), इसे कवर करता है।

अगर आप पूरा डेटा मॉडल और इंटीग्रेशन आर्किटेक्चर डिज़ाइन कर लें और उसके बाद सुनें कि “वैसे, इसे तीन orgs होना है,” तो आपने कोई छोटा बदलाव नहीं किया। आपने आर्किटेक्चर बदल दिया। इसीलिए यह फ़ैसला सबसे पहले आता है।

सिर्फ़ बॉक्स छोटे करने के लिए न बाँटें

एक बड़ा org पेचीदा लगता है: ढेर सारी यूनिट, ऑब्जेक्ट, यूज़र, इंटीग्रेशन। कोई कहता है, “क्या यह ज़्यादा साफ़ नहीं होगा अगर हर किसी का अपना org हो?” डायग्राम शायद साफ़ हो जाए। एंटरप्राइज़ शायद नहीं। आपने अंदरूनी पेचीदगी के बदले बिखरी हुई पेचीदगी ले ली: सिंक्रोनाइज़ेशन, डुप्लिकेट डेटा, cross-org पहचान, वैश्विक रिपोर्टिंग, कई release pipelines, दोहराए गए इंटीग्रेशन और ऑटोमेशन, और इन सब पर गवर्नेंस। कभी-कभी यह सौदा फिर भी सही होता है। लेकिन अलग होना सरल होने जैसा नहीं है।

और एक org भी मुफ़्त नहीं है। साझा गवर्नेंस ज़्यादा मायने रखता है, टीमें एक-दूसरे पर असर डाल सकती हैं, सिक्योरिटी की सीमाओं को सावधानी से डिज़ाइन करना पड़ता है, डेटा मॉडल को कई समूहों की सेवा करनी होती है, releases में तालमेल चाहिए, और क्षेत्रीय नियम सब पर पाबंदी लगा सकते हैं। तो बात “Steve कहता है हमेशा एक org” वाली नहीं है। मेरा शुरुआती झुकाव एक org की ओर है; फिर मैं वह ज़रूरत ढूँढता हूँ जो इतनी मज़बूत हो कि मुझे उससे हटा दे।

फ़ैसले को दिखने दें

अगर org रणनीति मायने रखती है, तो एक आम-सा Salesforce बादल न बनाएँ। orgs बनाएँ और उन पर लेबल लगाएँ (AMER, EMEA, जो भी असली हो), हर एक के पीछे की होस्टिंग या residency ज़रूरत लिखें, और कनेक्शनों पर चलकर देखें। किसी दूसरे आर्किटेक्ट को दिखना चाहिए कि हर सीमा क्यों है। अगर मैं नहीं समझा सकता कि तीन Salesforce बॉक्स क्यों हैं, तो मैंने फ़ैसला पूरा नहीं किया।

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

परीक्षा से आगे: AI क्या बदलता है। एक एजेंट org की सीमा को यूज़र के लिए अदृश्य बना सकता है। नीचे, आर्किटेक्चर को फिर भी तय करना होता है कि एजेंट किस org या सिस्टम से पूछ सकता है, कौन-सा डेटा क्षेत्रों के पार जा सकता है, और कौन-सा जवाब आधिकारिक है। AI अनुभव में पेचीदगी छिपा सकता है; वह गवर्नेंस या सीमा को नहीं हटाता।

आर्किटेक्ट यहाँ क्या तय करता है

• क्या एक से ज़्यादा org की कोई सच्ची आर्किटेक्चरल वजह है, बजाय फ़र्कों को एक ही org के अंदर हल करने के।
• हर org कहाँ चलता है, और कौन-सी residency, नियामक, अनुबंध संबंधी या बिज़नेस ज़रूरत उसे वहाँ रखती है।
• कौन-सा डेटा org और क्षेत्र की सीमाओं के पार जा सकता है, मास्टर डेटा कहाँ आधिकारिक है, और वैश्विक पहचान कैसे काम करती है।
• जब एक Salesforce बॉक्स कई बन जाता है, तो इंटीग्रेशन, identity, एनालिटिक्स और रिपोर्टिंग कैसे बदलते हैं।
• क्या अलगाव का फ़ायदा उस बिखरे हुए आर्किटेक्चर के लायक है जो वह बनाता है।

जब मैं कोई परिदृश्य पढ़ता हूँ, तो सबसे पहले यही फ़ैसला ढूँढता हूँ: एक org या कई, कहाँ होस्ट, और किस मजबूरी से? इनके जवाब दें, और बाकी लैंडस्केप आकार लेने लगता है।

और जानें

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), Chapter V (तीसरे देशों को व्यक्तिगत डेटा का ट्रांसफ़र) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।