मास्टर डेटा के चार तरीके

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

मॉड्यूल 2 (कुल 6 में से) — अध्याय मास्टर डेटा और पहचान, Data Architect कोर्स का अध्याय 6। हर मॉड्यूल अपने आप में पूरा है। पिछला: हर एट्रिब्यूट के लिए सच का एक स्रोत · अगला: मैचिंग, मर्जिंग और सर्वाइवरशिप

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

मॉड्यूल 1 ने कहा कि अधिकार एट्रिब्यूट-दर-एट्रिब्यूट तय होता है। अब: जब वे एट्रिब्यूट एक साथ कई सिस्टमों में रहते हैं, तब हम क्या करें? ग्राहक की जानकारी Salesforce में, ERP में, बिलिंग में, सपोर्ट में, शायद Data 360 में, शायद एक warehouse में, हर एक का अपना संस्करण। मास्टर डेटा मैनेजमेंट (MDM) इसी समस्या को हल करने की कोशिश करता है, और MDM कोई एक आर्किटेक्चर नहीं है। आप चार पैटर्न सुनेंगे: रजिस्ट्री, कंसॉलिडेशन, को-एग्ज़िस्टेंस (सह-अस्तित्व) और सेंट्रलाइज़्ड। ये प्रोडक्ट की सेटिंग नहीं हैं। ये एक ही सवाल के चार जवाब हैं: मास्टरिंग लेयर के पास कितना अधिकार है?

प्रोडक्ट से नहीं, समस्या से शुरू करें

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

रजिस्ट्री: बताओ कौन कौन है

सबसे हल्का पैटर्न। रजिस्ट्री स्रोतों की जगह नहीं लेती। ERP अपना ग्राहक रखता है, Salesforce अपना account, बिलिंग अपना ग्राहक, और रजिस्ट्री यह पता लगाती है कि ये रिकॉर्ड एक ही एंटिटी को दर्शाते हैं: Salesforce account 001…, ERP ग्राहक SAP-43821 और बिलिंग ग्राहक BILL-9127 एक ही ग्राहक के हैं। स्रोत अपनी जगह रहते हैं और ओवरराइट नहीं होते। अब “इस ग्राहक के बारे में हम जो कुछ जानते हैं, सब दिखाओ” का एक जवाब है।

लेकिन ध्यान दें कि रजिस्ट्री किस बात का जवाब नहीं देती। Salesforce कहता है 123 Main Street, ERP 125, बिलिंग “123 Main St., Suite 200।” रजिस्ट्री जानती है कि ये एक साथ हैं। वह यह तय नहीं करती कि किसे बदलना चाहिए। जोड़ना, मास्टर करना नहीं है।

मेरे अनुभव में, Salesforce प्रोजेक्ट्स पर रजिस्ट्री ही आम है, फिर कंसॉलिडेशन और को-एग्ज़िस्टेंस; शुद्ध सेंट्रलाइज़्ड MDM कम ही दिखता है। रजिस्ट्री आम इसलिए है क्योंकि वह दख़ल नहीं देती। फ़ायदा पाने से पहले आपको हर ऑपरेशनल सिस्टम दोबारा डिज़ाइन नहीं करना पड़ता। Salesforce वही करता रहता है जो वह करता है, ERP वही करता रहता है जो वह करता है, और आप एक आइडेंटिटी लेयर जोड़ देते हैं। यह हर सिस्टम से यह कहने से कहीं छोटा बदलाव है कि “अब ग्राहक डेटा आपके नियंत्रण में नहीं; यह नया केंद्रीय सिस्टम उसे नियंत्रित करता है।”

Click to enlarge

रजिस्ट्री जवाब देती है: कौन-से रिकॉर्ड एक ही एंटिटी के हैं?

कंसॉलिडेशन: डेटा को एक साथ लाएँ

कंसॉलिडेशन कई स्रोतों से डेटा लेकर उसे एक केंद्रीय रूप में जोड़ता है, रिपोर्टिंग, एनालिटिक्स, segmentation और ग्राहक की समझ के लिए। Warehouse जाना-पहचाना उदाहरण है: Salesforce ग्राहक भेजता है, ERP वित्तीय जानकारी, बिलिंग भुगतान, और बिज़नेस आख़िरकार सिस्टमों के पार ग्राहक का विश्लेषण कर पाता है। स्रोत अब भी मौजूद हैं और अब भी आधिकारिक हो सकते हैं। दिशा मायने रखती है: डेटा कंसॉलिडेटेड सिस्टम में आता है, जो आम तौर पर मास्टर किए गए बदलाव वापस नहीं भेजता। ग्राहक की बेहतर तस्वीर, उसका ऑपरेशनल अधिकारी बने बिना।

रजिस्ट्री और कंसॉलिडेशन को आपस में उलझाना आसान है। फ़र्क़ इसमें है कि केंद्र में क्या है: रजिस्ट्री पहचान को केंद्र में रखती है (“ये एक साथ हैं”); कंसॉलिडेशन डेटा का ज़्यादा हिस्सा केंद्र में लाता है (“एट्रिब्यूट को एक साथ लाओ ताकि हम उनका इस्तेमाल कर सकें”)। दोनों में से कोई यह नहीं कहता कि “अब यह केंद्रीय सिस्टम मास्टर है और हर ऐप्लिकेशन को इसके मान मानने होंगे।”

Click to enlarge

कंसॉलिडेशन स्रोतों से स्वामित्व छीने बिना डेटा को एक साथ लाता है।

को-एग्ज़िस्टेंस: तय करें, और वापस भेजें

को-एग्ज़िस्टेंस में मास्टरिंग लेयर को असली अधिकार मिलता है। डेटा अब भी कई ऑपरेशनल सिस्टमों में रहता है, लेकिन MDM प्रोसेस मास्टर किया हुआ मान तय करता है और उसे वापस प्रकाशित करता है। Salesforce, ERP और बिलिंग, तीनों में कानूनी नाम अलग है; MDM प्रोसेस नियंत्रित नाम तय करता है और उसे तीनों को बाँटता है। सिस्टम साथ-साथ रहते हैं, लेकिन मास्टर किए हुए मान पर आकर मिल जाते हैं।

यह MDM का कहीं ज़्यादा मज़बूत रूप है। यह यह नहीं कह रहा कि “ये एक साथ हैं”; यह कह रहा है कि “इस एट्रिब्यूट के लिए एंटरप्राइज़ यही मान इस्तेमाल करता है।” इसके लिए मैचिंग से ज़्यादा चाहिए: बिज़नेस नियम, स्वामित्व, सर्वाइवरशिप, दोतरफ़ा इंटीग्रेशन, एरर हैंडलिंग और गवर्नेंस, क्योंकि किसी को तय करना होता है कि एक मान क्यों जीतता है।

Click to enlarge

को-एग्ज़िस्टेंस सिर्फ़ रिकॉर्ड को जोड़ता नहीं। यह मास्टर किए हुए मान तय करता है और उन्हें वापस भेजता है।

सेंट्रलाइज़्ड: मास्टर सच बनाता है

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

Click to enlarge

सेंट्रलाइज़्ड MDM बनाने का काम और अधिकार, दोनों मास्टर में ले आता है।

चारों आमने-सामने

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

तालिका में नीचे जाते हुए, मास्टरिंग लेयर को ज़्यादा अधिकार मिलता है, और संगठन को आम तौर पर ज़्यादा बदलना पड़ता है।

परीक्षा-ज्ञान। चारों MDM implementation styles जानें: रजिस्ट्री (पहचानों को जोड़ती है; स्रोत अपना डेटा रखते हैं), कंसॉलिडेशन (डेटा को एक साथ लाता है, आम तौर पर विश्लेषण के लिए), को-एग्ज़िस्टेंस (मास्टर किए हुए मान तय करता है और उन्हें स्रोतों को वापस प्रकाशित करता है) और सेंट्रलाइज़्ड (मास्टर डेटा बनाता है; स्रोत उसका उपभोग करते हैं)।

इसलिए “सेंट्रलाइज़्ड सबसे परिपक्व है, तो सबको वहीं पहुँचना चाहिए” जैसी कोई बात नहीं है। वह सबसे हल्का पैटर्न चुनें जो समस्या हल कर दे। बस जानना है कि रिकॉर्ड एक साथ हैं? रजिस्ट्री के बारे में सोचें। एनालिटिक्स के लिए एक मिली-जुली नज़र? कंसॉलिडेशन। नियंत्रित मान कई ऑपरेशनल सिस्टमों में वापस सिंक करने हैं? को-एग्ज़िस्टेंस। एक प्रोसेस जो सबके लिए मास्टर डेटा बनाए और नियंत्रित करे? सेंट्रलाइज़्ड।

Data 360 कहाँ फ़िट होता है?

Data 360 कई स्रोतों के पार यूनिफ़ाइड प्रोफ़ाइल बनाता है, जो काफ़ी हद तक MDM जैसा लगता है, और यह समस्या का एक हिस्सा हल भी करता है। इसका आइडेंटिटी रेज़ोल्यूशन स्रोत प्रोफ़ाइलों को मिलाकर एक unified identity बनाता है और स्रोत रिकॉर्ड तक वापस के लिंक रखता है (Data 360 Architecture (opens in a new tab))। इससे यह रजिस्ट्री के सबसे क़रीब है। यह यूनिफ़ाइड प्रोफ़ाइल पर मिलान किए गए (reconciled) मान भी दिखा सकता है। लेकिन इससे यह स्रोतों को दोबारा लिखने वाला सेंट्रलाइज़्ड गोल्डन-रिकॉर्ड सिस्टम नहीं बन जाता। एक यूनिफ़ाइड नज़र अपने-आप एक मास्टर किया हुआ एंटरप्राइज़ रिकॉर्ड नहीं है। मॉड्यूल 4 पूरा इसी अंतर के बारे में है।

साझा मॉडल, साझा सच नहीं है

आप कैनॉनिकल डेटा मॉडल (canonical data model) भी सुनेंगे। Salesforce का Account, ERP का business partner और बिलिंग का customer, सब एक तय एंटरप्राइज़ अवधारणा, Customer, से मैप होते हैं, जिसके तय ID और एट्रिब्यूट होते हैं, ताकि हर इंटीग्रेशन को हर दूसरे सिस्टम का आकार न समझना पड़े। Data 360 का डेटा मॉडल स्रोतों को साझा अवधारणाओं में सामंजस्य (harmonization) से लाने का एक उदाहरण है। लेकिन कैनॉनिकल मॉडल जवाब देता है कि हम इसे एक जैसा कैसे दर्शाएँ? MDM जवाब देता है कि हम सिस्टमों के पार इसे कैसे पहचानें, नियंत्रित करें और मास्टर करें? तीनों सिस्टमों को एक Customer आकार में बिल्कुल सही मैप कर दें, फिर भी Salesforce कहता है 123 Main Street और ERP कहता है 125। आपने संरचना हल की है, अधिकार नहीं। सामंजस्य और मास्टरिंग एक-दूसरे की जगह नहीं ले सकते।

एक बिज़नेस, कई पैटर्न

इसलिए “Steve Trucking को MDM चाहिए” कोई ज़रूरत नहीं है। किस चीज़ के लिए? रिटेल पार्टनर, डिस्ट्रिब्यूशन सेंटर, क्रू, ट्रक, प्राप्तकर्ता अलग-अलग डोमेन हैं, जिनके अधिकार अलग हैं: रिटेल पार्टनर Salesforce और फ़ाइनेंस ERP में नियंत्रित, ट्रक की पहचान FleetLink से, और हर प्राप्तकर्ता हर डिलीवरी के लिए किसी पार्टनर से आता है। अलग डोमेन अलग पैटर्न ले सकते हैं, और एक डोमेन के अंदर भी एट्रिब्यूट के अलग अधिकार हो सकते हैं। इसलिए डायग्राम के बीच में MDM लिखा एक बॉक्स बनाकर उसे हल मत मान लीजिए। पूछें कि वह बॉक्स करता क्या है।

शैली इंटीग्रेशन को भी बदल देती है। रजिस्ट्री को आइडेंटिटी लिंक चाहिए; कंसॉलिडेशन को भरोसेमंद अंदर आने वाले flow; को-एग्ज़िस्टेंस को दोनों दिशाओं में डेटा; सेंट्रलाइज़्ड को मास्टर से बँटवारा, साथ में ऐसे नियंत्रण जो दूसरे सिस्टमों को प्रतिद्वंद्वी सच बनाने से रोकें। जैसे-जैसे अधिकार बढ़ता है, तालमेल भी बढ़ता है, और विफलता को संभालना भी: अगर MDM कानूनी नाम बदल दे और ERP उसे अस्वीकार कर दे तो? इसीलिए को-एग्ज़िस्टेंस और सेंट्रलाइज़्ड “ज़्यादा फ़ीचर वाली रजिस्ट्री” नहीं हैं। उनकी ऑपरेशनल ज़िम्मेदारियाँ अलग हैं।

MDM एक बिज़नेस फ़ैसला है

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

जो सामान्य सबक मैंने ठोकरें खाकर सीखा है: जब कई सिस्टम एक ही डेटा को मास्टर करते हैं, तो जिस बात पर वे सहमत नहीं, उसे Salesforce नहीं सुलझा सकता। जब कोई कंपनी दो ERP चलाती है, तो मैं पूछता हूँ कि वे उन्हें सिंक में कैसे रखते हैं। अगर वे नहीं रख पाते, तो Salesforce भी नहीं रख पाएगा। मॉड्यूल 5 वह कहानी सुनाता है (एक ग्राहक, दो ERP)।

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

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

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

और जानें

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।