गवर्नेंस 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 1 (कुल 6 में से) — अध्याय डेटा गुणवत्ता और गवर्नेंस, Data Architect कोर्स का अध्याय 5। हर मॉड्यूल अपने आप में पूरा है। अगला: खराब डेटा को बाहर रखना

यह मॉड्यूल किस सवाल का जवाब देता है: एक आर्किटेक्ट के लिए डेटा गवर्नेंस का क्या मतलब है, और कौन क्या करता है?

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

अगर नीति कहती है कि कोई फ़ील्ड सिर्फ़ Finance बदल सकता है, तो उसे कौन लागू करता है? अगर वह कहती है कि कानूनी ग्राहक रिकॉर्ड का मालिक ERP है, तो Salesforce में किसी को उसे बदलने से कौन रोकता है? अगर वह कहती है कि क्रू किसी प्राप्तकर्ता का पता सिर्फ़ अपने स्टॉप के लिए, सिर्फ़ उसी दिन देखें, तो असल में इसे सच कौन बनाता है? अगर वह कहती है कि इसे सात साल रखो, तो सात साल बाद इसे कौन आर्काइव करता है या हटाता है? लागू करने के बिंदु के बिना नीति ज़्यादातर बस एक इच्छा है। गवर्नेंस तब आर्किटेक्चर बनती है जब ये फ़ैसले सिस्टम में बना दिए जाते हैं।

गवर्नेंस कभी पूरी नहीं होती

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

जब Salesforce ज़्यादातर अकेला खड़ा हो, तो गवर्नेंस का मतलब है एक जगह डेटा साफ़ करना। जब वह अध्याय 4 के लैंडस्केप का एक नोड हो, तो यह ज़्यादा मुश्किल और ज़्यादा ज़रूरी हो जाती है। अब ग्राहक Salesforce, ERP, वेयरहाउस, पार्टनर सिस्टम और Data 360 में रहता है। उसका मालिक कौन है? उसे कौन बदल सकता है? कौन-सी कॉपी आधिकारिक है, कौन-से एट्रिब्यूट आगे जा सकते हैं, वे कितने समय रखे जाते हैं, और गलत होने पर जवाब कौन देता है? ये कॉन्फ़िगरेशन के सवाल नहीं हैं। ये गवर्नेंस के सवाल हैं जो कॉन्फ़िगरेशन बन जाते हैं।

रिकॉर्ड का मालिक डेटा का मालिक नहीं है

मालिक (owner) शब्द से शुरू करते हैं, क्योंकि Salesforce इसे उलझा देता है। कोई Account खोलें और आपको एक Owner दिखता है: मान लीजिए एक सेल्स रिप। क्या वह रिप ग्राहक डेटा का मालिक है? ज़रूरी नहीं। Salesforce पर, owner वाले ऑब्जेक्ट का रिकॉर्ड किसी यूज़र या क्यू का होता है; owner को पूरा एक्सेस मिलता है, और owner रोल हायरार्की और शेयरिंग रूल के ज़रिए असाइनमेंट और शेयरिंग चलाता है (Sharing and Record Access Features (opens in a new tab))। यह रिकॉर्ड का स्वामित्व है: प्लेटफ़ॉर्म का एक तरीका।

डेटा का मालिक कुछ और है: वह व्यक्ति या विभाग जो एक बिज़नेस संपत्ति के रूप में डेटा के लिए जवाबदेह है। कानूनी ग्राहक जानकारी का मालिक Finance हो सकता है, डिलीवरी स्टेटस का Operations, कर्मचारी डेटा का HR। Salesforce आपको इसे दर्ज करने की जगह भी देता है: हर फ़ील्ड पर Data Owner वर्गीकरण फ़ील्ड (Data Classification Metadata Fields (opens in a new tab))।

Steve Trucking में, किसी रिटेल पार्टनर के Account का owner वह सेल्स एग्ज़िक्यूटिव हो सकता है जो उस पार्टनर को संभालता है। लेकिन पार्टनर की कानूनी पहचान को Finance गवर्न करता है और वह फ़ाइनेंस ERP में मास्टर होती है। सेल्स, सर्विस, ऑपरेशंस और पार्टनर पोर्टल, सबको Account चाहिए; इसका यह मतलब बिल्कुल नहीं कि Finance के तय कर देने के बाद सेल्स एग्ज़िक्यूटिव पार्टनर की कानूनी पहचान बदले। मैंने टीमों को Owner फ़ील्ड देखकर यह मानते देखा है कि उन्होंने डेटा का स्वामित्व हल कर लिया। नहीं किया। रिकॉर्ड असाइनमेंट बिज़नेस की जवाबदेही नहीं है।

मालिक, स्टीवर्ड, कस्टोडियन

गवर्नेंस की तीन भूमिकाएँ, तीन अलग काम।

डेटा का मालिक नीति तय करता है। वह इन सवालों के जवाब देता है: डेटा का मतलब क्या है, उसे कौन बना और बदल सकता है, उसे कितना सटीक होना चाहिए, उसे कितने समय रखा जाता है, उसे कौन देख सकता है, कौन-सा सिस्टम आधिकारिक है, और गलत होने पर क्या होता है। आर्किटेक्ट को ये जवाब गढ़ने नहीं चाहिए। यह मेरे सबसे पक्के मतों में से एक है: नीति मालिक तय करते हैं; आर्किटेक्ट उसे लागू करते हैं। अगर Finance कहता है कि ग्राहक के सक्रिय होने के बाद कानूनी नाम सिर्फ़ ERP की प्रक्रिया से बदल सकता है, तो यह गवर्नेंस का फ़ैसला है। इसे मशीनी तौर पर सच बनाना मेरा काम है।

डेटा स्टीवर्ड इसे चालू रखता है। स्टीवर्ड डेटा की रोज़मर्रा की सेहत के करीब होता है: गुणवत्ता के संकेतों पर नज़र रखना, डुप्लिकेट की जाँच, अपवादों को सुलझाना, सुधारों का तालमेल, परिभाषाओं को बनाए रखना, और उस प्रक्रिया को पकड़ना जो बार-बार खराब डेटा पैदा करती है। दो और काम स्टीवर्ड के पास हैं। जब दो टीमें इस पर असहमत हों कि किसी फ़ील्ड का मतलब क्या है, उसका मालिक कौन है या उसे कौन देख सकता है, तो स्टीवर्ड विवाद मालिक तक ले जाता है और फ़ैसले को अमल तक पहुँचाता है। और स्टीवर्ड डेटा साक्षरता (data literacy) बनाता है: डेटा दर्ज करने और इस्तेमाल करने वाले लोगों को यह समझने में मदद करता है कि उसका मतलब क्या है और नियम क्यों हैं। स्टीवर्ड को चार्ट पर एक नाम से ज़्यादा चाहिए। उसे समय, विज़िबिलिटी, एक प्रक्रिया, और समस्याएँ ठीक करवाने का अधिकार चाहिए। वरना “डेटा स्टीवर्ड” किसी की आठवीं ज़िम्मेदारी बन जाता है, जिसे तिमाही में एक बार देखा जाता है।

कस्टोडियन सिस्टम चलाता है। एडमिन, प्लेटफ़ॉर्म टीमें, सिक्योरिटी टीमें: जो भी उस टेक्नोलॉजी को चलाता है जो डेटा को स्टोर और प्रोसेस करती है। मालिक कहता है कि इसे सिर्फ़ ये भूमिकाएँ देख सकती हैं; कस्टोडियन वे कंट्रोल चलाता है जो ऐसा करवाते हैं। नामों से ज़्यादा ज़रूरी है हर जवाबदेही को साफ़ करना, और किसी छोटे संगठन में एक ही व्यक्ति दो भूमिकाएँ निभा सकता है।

प्रोग्राम कैसे चलता है

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

परीक्षा-ज्ञान। गवर्नेंस प्रोग्राम चलाने के तीन तरीके जानें, सेंट्रलाइज़्ड, फ़ेडरेटेड (विकेंद्रीकृत) और हाइब्रिड, और यह कि हर एक का इस पर क्या असर है कि नीति कौन तय करता है और साझा परिभाषाएँ कहाँ रहती हैं।

RACI को अपनी जगह कमानी होगी

एक RACI (कौन Responsible, Accountable, Consulted और Informed है) मदद करता है, लेकिन कोई विशाल स्प्रेडशीट नहीं जो इसलिए बनाई गई क्योंकि गवर्नेंस को “एक चाहिए।” मैं चाहता हूँ कि यह आर्किटेक्चर के सवालों का जवाब दे, अध्याय 4 के तीन सवालों से शुरू करके (श्रेणियों के पीछे के चार सवाल): डेटा कहाँ बनता है, कहाँ बदला जाता है, और कहाँ उसका हवाला दिया जाता है? अक्सर ये अलग-अलग सिस्टम होते हैं। एक प्रोडक्ट लें: ERP उसे बनाता है, Salesforce उसका हवाला देता है, पोर्टल उसे दिखाता है, वेयरहाउस उसका विश्लेषण करता है। अब बिज़नेस “सक्रिय प्रोडक्ट” का मतलब बदल देता है। बदलाव कहाँ से शुरू होता है, उसे कौन मंज़ूर करता है, वह कैसे फैलता है, और कौन-सी कॉपियाँ सिर्फ़ पढ़ने के लिए हैं? अगर आप जवाब नहीं दे सकते, तो आपके पास अभी गवर्नेंस नहीं है। आपके पास कॉपियाँ हैं। एक अच्छा RACI ठीक यही अस्पष्टता उजागर करता है।

गवर्नेंस को मशीनी बनना होगा

बिज़नेस कहता है कि कानूनी ग्राहक नाम सिर्फ़ Finance बदल सकता है। मैं नहीं चाहता कि आर्किटेक्चर का जवाब हो “हम इसे ट्रेनिंग में बता देंगे।” ट्रेनिंग मदद करती है; वह लागू करना नहीं है। शायद यह फ़ील्ड-लेवल एक्सेस हो, एक वैलिडेशन रूल, ऐसा फ़ील्ड जिसे सिर्फ़ इंटीग्रेशन लिखता है, या सीधे बदलाव के बजाय एक नियंत्रित प्रक्रिया। तरीका आवश्यकता पर निर्भर करता है, लेकिन कोई तरीका होना ज़रूर चाहिए:

गवर्नेंस नीति	कौन तय करता है	लागू करने का संभावित बिंदु
कानूनी ग्राहक पहचान का मालिक ERP है	Finance	सिर्फ़ इंटीग्रेशन वाले फ़ील्ड, परमिशन, वैलिडेशन
व्यक्तिगत डेटा सिर्फ़ ज़रूरत वाले लोग देखें	प्राइवेसी, सिक्योरिटी	शेयरिंग, परमिशन, फ़ील्ड एक्सेस
ग्राहक पहचानकर्ता यूनिक हों	बिज़नेस मालिक	यूनिक External ID, डुप्लिकेट रूल
गवर्न किए गए रिकॉर्ड हाथ से न बनें	डेटा का मालिक	परमिशन, ऑटोमेशन, इंटीग्रेशन
संवेदनशील डेटा की एक तय रिटेंशन अवधि हो	प्राइवेसी, लीगल	रिटेंशन या डिलीशन की एक प्रक्रिया
अहम बदलाव साबित किए जा सकें	कम्प्लायंस	फ़ील्ड हिस्ट्री, ऑडिट ट्रेल
डेटा का स्रोत पहचाना जा सके	डेटा का मालिक	एक सोर्स फ़ील्ड, लिनिएज मेटाडेटा

मैं जान-बूझकर संभावित बिंदु कहता हूँ। यह फ़ीचर चुनने की टेबल नहीं है। यह सोचने का क्रम है: नीति क्या है, उसका मालिक कौन है, और आर्किटेक्चर में क्या उसे सच बनाता है?

Click to enlarge

नीति मालिक तय करते हैं; आर्किटेक्ट उसे लागू करते हैं।

अच्छे बर्ताव पर भरोसा न करें

“ERP का ग्राहक ID कभी मत बदलना।” यह सबको पता है, जब तक कोई बदल न दे: गलती से, किसी डेटा लोड से, ऑटोमेशन से, किसी इंटीग्रेशन से, किसी एजेंट से। अगर इसे बदलने से एंटरप्राइज़ डेटा को नुकसान होगा, तो “कृपया न करें” कोई कंट्रोल नहीं है। कंट्रोल बनाएँ। भरोसा करें, पर जाँचें। लोग, इंटीग्रेशन, ऑटोमेशन और AI, सभी गलतियाँ करते हैं, इसलिए आर्किटेक्चर को यह मानकर चलना चाहिए कि कभी न कभी कोई चीज़ वह करने की कोशिश करेगी जिसे नीति मना करती है। तब क्या होगा?

गवर्नेंस सिस्टम की सीमाओं को पार करती है

वापस लैंडस्केप पर। ग्राहक का मालिक ERP है; Salesforce, वेयरहाउस और एक कस्टमर डेटा प्लेटफ़ॉर्म के पास कॉपियाँ हैं; किसी पार्टनर को उसका कुछ हिस्सा मिलता है। नीति किस सिस्टम पर लागू होती है? सब पर। हो सकता है Salesforce कानूनी नाम का बदलाव सही ढंग से रोक दे, जबकि कोई इंटीग्रेशन किसी डाउनस्ट्रीम सिस्टम को उसे ओवरराइट करने दे। हो सकता है Salesforce वह व्यक्तिगत डेटा डिलीट कर दे जो वेयरहाउस में अब भी है। Salesforce में संवेदनशील के रूप में वर्गीकृत फ़ील्ड कहीं और किसी अवर्गीकृत टेक्स्ट फ़ील्ड में पहुँच सकता है। गवर्नेंस org की सीमा पर नहीं रुक सकती, क्योंकि डेटा नहीं रुकता। इसीलिए अध्याय 4 पहले आया: लैंडस्केप बताता है कि गवर्नेंस को कितनी दूर तक पहुँचना है।

ज़रूरत भर गवर्न करें, सब कुछ नहीं

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

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

परीक्षा से आगे: AI क्या बदलता है। गवर्नेंस का एक नया उपभोक्ता है: एजेंट। डेटा का मालिक अब भी तय करता है कि क्या इस्तेमाल हो सकता है और किस काम के लिए; आर्किटेक्ट अब भी उसे लागू करने लायक बनाता है। जो बदलता है वह है रफ़्तार और पैमाना। एजेंट गवर्न किए गए डेटा को किसी इंसान से कहीं तेज़ी से पढ़ता, जोड़ता और उस पर काम करता है, इसलिए जो नीति सिर्फ़ किसी दस्तावेज़ में है, वह और भी कम बचाती है।

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

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

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

और जानें

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।