7.9 मास्टर डेटा और संदर्भ डेटा प्रबंधन

अवलोकन और प्रेरणा

पाँच सिस्टम से पूछें कि संगठन के पास कितने ग्राहक हैं, और आपको पाँच अलग-अलग संख्याएँ मिलेंगी। एक ईमेल पते गिनता है, एक अनुबंध गिनता है, एक लॉगिन गिनता है, और दो इस बात पर असहमत हैं कि क्या “Acme Corp” और “ACME Corporation” एक ही कंपनी हैं। मास्टर डेटा प्रबंधन (MDM) उस अनुशासन का नाम है जो आपके व्यवसाय की साझा मूल इकाइयों, ग्राहक, उत्पाद, आपूर्तिकर्ता, कर्मचारी, स्थान, को एक ऐसे प्रामाणिक संस्करण में सुलझाता है जिस पर हर सिस्टम भरोसा कर सके।

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

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

दशकों की वृद्धि और अधिग्रहण से जमा हुए सिस्टम को सुलझाने वाले एंटरप्राइज़ के लिए, MDM एक सुसंगत ग्राहक दृष्टिकोण और एक स्थायी सामंजस्य कर के बीच का अंतर है। सरकार के लिए, दांव बढ़ जाते हैं: एक नागरिक जो तीन एजेंसियों में तीन अलग-अलग व्यक्तियों के रूप में दिखाई देता है उसे कोई लाभ अस्वीकार किया जा सकता है, दो बार कर लगाया जा सकता है, या विभागों के बीच खो दिया जा सकता है। यह अध्याय डेटा रणनीति और गवर्नेंस (अध्याय 7.1) का पूरक है, जो स्वामित्व और नीति तय करता है; डेटा मॉडलिंग और सिमेंटिक लेयर (अध्याय 7.7), जो परिभाषित करता है कि इकाइयों का क्या अर्थ है; और डेटा गुणवत्ता और ऑब्ज़र्वेबिलिटी (अध्याय 7.8), जो समय के साथ रिकॉर्ड को साफ़ रखता है।

मुख्य सिद्धांत

• अपने डेटा को मास्टर, संदर्भ, और लेन-देन में छाँटें; हर एक को अलग व्यवहार चाहिए।
• हर वास्तविक-दुनिया इकाई के लिए एक गोल्डन रिकॉर्ड, जानबूझकर इकट्ठा किया गया, दुर्घटनावश खोजा नहीं गया।
• अपनी नियंत्रण और विलंबता आवश्यकताओं के अनुरूप एक MDM आर्किटेक्चर शैली चुनें, फैशन के अनुसार नहीं।
• मिलान (मैचिंग) और सर्वाइवरशिप व्यावसायिक नियम हैं, इसलिए उन्हें लिख लें और स्टीवर्ड को उन्हें ट्यून करने दें।
• संदर्भ डेटा साझा शब्दावली है; इसे वर्ज़न करें और इसे एक API की तरह प्रकाशित करें।
• गवर्नेंस और स्टीवर्डशिप MDM का इंजन हैं; सॉफ़्टवेयर केवल टूलिंग है।
• गोल्डन रिकॉर्ड को इवेंट के रूप में प्रचारित करें ताकि डाउनस्ट्रीम सिस्टम सिंक में रहें, बासी नहीं।
• MDM को सुधरे गए निर्णयों और हटाए गए डुप्लिकेट से मापें, लोड किए गए रिकॉर्ड से नहीं।

सिफारिशें

पहले मास्टर, संदर्भ, और लेन-देन डेटा को वर्गीकृत करें

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

जानबूझकर एक MDM आर्किटेक्चर शैली चुनें

चार सामान्य आर्किटेक्चर शैलियाँ हैं, और सही शैली इस पर निर्भर करती है कि आप कितना अधिकार केंद्रीकृत कर सकते हैं और परिवर्तनों को कितनी तेज़ी से फैलना चाहिए। रजिस्ट्री शैली डेटा को स्रोत सिस्टम में छोड़ देती है और केवल मिलान की गई पहचानकर्ताओं का एक इंडेक्स बनाती है, ताकि वह बिना कोई डेटा हिलाए “ये पाँच रिकॉर्ड एक ही ग्राहक हैं” का जवाब दे सके; यह सस्ती और कम-जोखिम वाली है, लेकिन केवल-पढ़ने योग्य है, इसलिए यह स्रोतों को ठीक नहीं कर सकती। समेकन (consolidation) शैली प्रतियों को एक केंद्रीय हब में खींचती है और उन्हें रिपोर्टिंग के लिए गोल्डन रिकॉर्ड में मर्ज करती है, लेकिन सुधार वापस नहीं भेजती, इसलिए स्रोत गड़बड़ बने रहते हैं। सह-अस्तित्व (coexistence) शैली आगे जाती है: यह साफ़ किए गए मूल्यों को वापस स्रोत सिस्टम में सिंक्रोनाइज़ करती है, ताकि स्रोत स्वतंत्र रूप से काम करते हुए भी समय के साथ सुधरें। केंद्रीकृत या ट्रांज़ैक्शनल हब शैली MDM हब को ही रिकॉर्ड का सिस्टम बनाती है, जहाँ इकाइयाँ सीधे बनाई और संपादित की जाती हैं और हर अन्य सिस्टम उसी से उपभोग करता है; यह सबसे मज़बूत संगति और नियंत्रण देती है, और इसे अपनाना सबसे कठिन है क्योंकि यह बदल देती है कि काम कहाँ होता है। कई संगठन एक रजिस्ट्री से जो मूल्य साबित करती है, विश्वास बढ़ने के साथ सह-अस्तित्व की ओर बढ़ते हैं, और अलग-अलग डोमेन में एक से अधिक शैली चलाते हैं।

मिलान करें, मर्ज करें, और सर्वाइवरशिप नियम स्पष्ट रूप से तय करें

MDM का मूल यह तय करना है कि कब दो रिकॉर्ड एक ही वास्तविक-दुनिया चीज़ का वर्णन करते हैं। यह रिकॉर्ड लिंकेज है, जो शायद ही कभी एक सटीक कुंजी मिलान जितना सरल होता है क्योंकि वास्तविक डेटा टाइपो, संक्षिप्ताक्षरों, और गुम फ़ील्ड से भरा होता है। नियतात्मक (deterministic) मिलान चुने गए फ़ील्ड पर सटीक नियमों का उपयोग करता है (वही कर पहचान संख्या, या वही ईमेल साथ में डाक कोड)। संभाव्य (probabilistic) मिलान अनुमानित स्ट्रिंग मिलान और भार का उपयोग करते हुए कई फ़ील्ड में समानता का स्कोर करता है, ताकि “Bob Smith, 12 Main St” और “Robert Smith, 12 Main Street” को एक सीमा से ऊपर एक संभावित मिलान माना जा सके। यह तय करना कि कौन से रिकॉर्ड एक ही इकाई को संदर्भित करते हैं, पहचान समाधान (identity resolution) कहलाता है, और यह ग्राहक दृष्टिकोण से लेकर धोखाधड़ी का पता लगाने तक सब कुछ संचालित करता है।

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

संदर्भ डेटा को वर्ज़न की गई साझा शब्दावली के रूप में मानें

संदर्भ डेटा वह साझा शब्दावली है जिसे आपके सिस्टम बोलते हैं, और शब्दावली जो बहती है वह मौन गलत-संरेखण का कारण बनती है: जब एक सिस्टम ISO देश कोड “GB” का उपयोग करता है और दूसरा “UK” का, तो जॉइन विफल हो जाते हैं और गिनती अलग हो जाती है। हर संदर्भ सूची को एक गवर्न किए गए स्थान पर बनाए रखें, इसे हर उपभोक्ता के लिए प्रकाशित करें, और, महत्वपूर्ण रूप से, इसे वर्ज़न करें। कोड समय के साथ जोड़े जाते हैं, रिटायर किए जाते हैं, विभाजित किए जाते हैं, और मर्ज किए जाते हैं, और यदि आप सूची को उसी स्थान पर ओवरराइट कर देते हैं, तो आप उन ऐतिहासिक रिपोर्ट को तोड़ देते हैं जो पुराने कोड के अंतर्गत सही थीं।

एक संदर्भ डेटासेट को एक अनुबंध वाले API की तरह मानें। इसे प्रभावी तिथियों के साथ प्रकाशित करें ताकि एक उपभोक्ता पूछ सके “इस तिथि पर मान्य क्षेत्र कोड क्या थे,” रिटायर किए गए कोड को हटाने की बजाय रखें, और जब किसी कोड का अर्थ बदले तो मैपिंग रिकॉर्ड करें। जहाँ मौजूद हों वहाँ मान्यता प्राप्त बाहरी मानकों को प्राथमिकता दें, जैसे ISO देश और मुद्रा कोड, क्योंकि मानक आपको मुफ्त में इंटरऑपरेबिलिटी देते हैं और अध्याय 3.8 में ओपन-स्टैंडर्ड अनुशासन से जुड़ते हैं।

पदानुक्रम और संबंधों का मॉडलिंग करें, न कि केवल सपाट रिकॉर्ड का

मास्टर डेटा स्वतंत्र पंक्तियों का ढेर नहीं है; यह संबंधों का एक जाल है। एक ग्राहक एक परिवार और एक कॉर्पोरेट पैरेंट से संबंधित होता है। एक उत्पाद एक श्रेणी और एक ब्रांड में समाहित होता है। ये पदानुक्रम वास्तविक व्यावसायिक अर्थ रखते हैं: कॉर्पोरेट पैरेंट द्वारा बिक्री को समेकित करें और तस्वीर व्यक्तिगत खाते द्वारा समेकित करने से पूरी तरह बदल जाती है। इन संबंधों को स्पष्ट रूप से मॉडल करें ताकि उपभोक्ता उन्हें लगातार तरीके से पार करें बजाय इसके कि हर टीम अपना खुद का समेकन आविष्कार करे।

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

गोल्डन रिकॉर्ड को सिमेंटिक लेयर और डेटा गुणवत्ता में जोड़ें

MDM जो गोल्डन रिकॉर्ड उत्पन्न करता है वे वे विश्वसनीय इकाइयाँ हैं जिन्हें अध्याय 7.7 की सिमेंटिक लेयर संदर्भित करती है जब वह मेट्रिक्स परिभाषित करती है: “सक्रिय ग्राहक” का कोई अर्थ तभी होता है जब “ग्राहक” स्पष्ट हो। अपने गोल्डन रिकॉर्ड को सिमेंटिक लेयर में फ़ीड करें ताकि हर मेट्रिक उन्हीं डुप्लिकेट-मुक्त, हल की गई इकाइयों को गिने।

MDM और डेटा गुणवत्ता (अध्याय 7.8) एक ही सिक्के के दो पहलू हैं: गुणवत्ता जाँच डुप्लिकेट, नल, और फ़ॉर्मैट उल्लंघन का पता लगाती है जिन्हें MDM फिर हल करता है, और MDM का मिलान उन गुणवत्ता समस्याओं को सामने लाता है जिन्हें जाँच ने छोड़ दिया। अपने मास्टर डेटा पर विशेष रूप से निरंतर गुणवत्ता निगरानी चलाएँ: डुप्लिकेट दरें, मिलान विश्वास वितरण, मुख्य फ़ील्ड की पूर्णता, और समीक्षा कतार का आकार, ताकि बहाव उपभोक्ताओं के देखने से पहले सामने आए।

इवेंट के माध्यम से गोल्डन रिकॉर्ड प्रचारित करें

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

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

टूलिंग से पहले स्टीवर्डशिप और गवर्नेंस तय करें

MDM एक प्रौद्योगिकी परियोजना के रूप में विफल होता है और एक गवर्नेंस परियोजना के रूप में सफल होता है। महत्वपूर्ण भूमिका डेटा स्टीवर्ड की है, एक ऐसा व्यक्ति जो किसी विशिष्ट डोमेन की गुणवत्ता और नियमों के लिए जवाबदेह हो, जो अस्पष्ट मिलानों को हल करता है, सर्वाइवरशिप नियमों को ट्यून करता है, और तब मध्यस्थता करता है जब दो विभाग इस बात पर असहमत हों कि “आपूर्तिकर्ता” का क्या अर्थ है। स्टीवर्ड आमतौर पर गहरे डोमेन ज्ञान वाले व्यावसायिक लोग होते हैं, इंजीनियर नहीं, और उन्हें वास्तविक अधिकार और आवंटित समय चाहिए, क्योंकि बिना किसी आदेश के अंशकालिक स्टीवर्डशिप ठीक वही बहाव पैदा करती है जिसे रोकने के लिए MDM था।

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

व्यापार-संतुलन: फायदे और नुकसान

MDM शैली	फायदे	नुकसान
रजिस्ट्री (केवल इंडेक्स)	सस्ती, कम-जोखिम, स्रोत अछूते	केवल-पढ़ने योग्य; स्रोत डेटा ठीक नहीं कर सकती
समेकन (केंद्रीय प्रतियाँ)	एनालिटिक्स के लिए तेज़ी से साफ़ रिकॉर्ड	स्रोत गड़बड़ बने रहते हैं; कोई राइटबैक नहीं
सह-अस्तित्व (स्रोतों को वापस सिंक)	स्रोत सुधरते हैं; संतुलित नियंत्रण	अधिक इंटीग्रेशन; प्रबंधित करने के लिए सिंक टकराव
केंद्रीकृत / ट्रांज़ैक्शनल हब	सबसे मज़बूत संगति और नियंत्रण	उच्चतम लागत; काम कहाँ होता है यह बदलता है
नियतात्मक मिलान	पूर्वानुमेय, समझाने योग्य, ऑडिट योग्य	टाइपो, वेरिएंट, और गड़बड़ डेटा छूट जाता है
संभाव्य मिलान	वास्तविक-दुनिया विविधता पकड़ता है	ट्यूनिंग की आवश्यकता; असावधानी पर गलत मर्ज

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

2. हर मास्टर डेटा डोमेन का मालिक कौन है, और क्या हमारे स्टीवर्ड के पास वास्तव में काम करने का अधिकार और समय है? बिना सशक्त स्टीवर्डशिप के MDM टूलिंग बिना ड्राइवर की कार है, और सबसे सामान्य विफलता मोड एक स्लाइड पर एक स्टीवर्ड को नाम देना है जबकि उन्हें कोई वास्तविक आदेश या आवंटित घंटे न देना। जो लोग अस्पष्ट मिलानों को हल करते हैं और “क्या ग्राहक माना जाता है” के विवादों को सुलझाते हैं उन्हें डोमेन विशेषज्ञता, निर्णय अधिकार, और संरक्षित समय चाहिए। अपना संगठन चार्ट लाएँ और पूछें, अपने शीर्ष डोमेन के लिए, ठीक-ठीक कौन तय करता है कि दो रिकॉर्ड एक ही व्यक्ति हैं, और कौन तब मध्यस्थता करता है जब बिक्री और वित्त असहमत हों। यदि आप उस व्यक्ति का नाम नहीं बता सकते और उनके आवंटित समय की ओर इशारा नहीं कर सकते, तो आपने वह अंतराल खोज लिया है जो कार्यक्रम को डुबो देगा।

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

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

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

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

क्षेत्रीय दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

MDM पर प्रतिफल एक ऐसे कर को हटाने से आता है जिसे अधिकांश संगठन बिना उसका नाम लिए चुकाते हैं। डुप्लिकेट और परस्पर विरोधी रिकॉर्ड स्पष्ट तरीकों से पैसा खर्च कराते हैं (एक ही व्यक्ति को पाँच बार बर्बाद मार्केटिंग, बासी पतों से शिपिंग त्रुटियाँ, छूटी हुई मात्रा छूट) और कम स्पष्ट तरीकों से (विश्लेषक गिनती का सामंजस्य बिठाते हुए, अधिकारी उन संख्याओं पर निर्णय लेते हुए जो चुपचाप गलत हैं, ऑडिटर यह सुलझाने में घंटे बिल करते हुए कि कौन सा रिकॉर्ड वास्तविक है)। एक समेकित आपूर्तिकर्ता दृष्टिकोण अक्सर बेहतर अनुबंध शर्तों के माध्यम से अकेले ही पूरे कार्यक्रम की लागत चुका देता है।

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

1. यदि आपके दो सिस्टम इस बात पर असहमत हैं कि आपके कितने ग्राहक हैं, तो कौन सा सही है, और आप इसे कैसे साबित करेंगे?
2. यदि आप इसमें सबसे पहले महारत हासिल करें तो कौन सा मास्टर डेटा डोमेन सबसे बड़ी मापने योग्य जीत देगा, और वह जीत कितनी मूल्यवान है?
3. आज संभाव्य मिलान आपकी कहाँ मदद करेगा, और क्या आप उससे निहित कभी-कभार गलत मर्ज के साथ सहज हैं?
4. आप अपने संदर्भ डेटा को कैसे वर्ज़न करते हैं, और जब कोई कोड अर्थ बदलता है तो आपकी ऐतिहासिक रिपोर्ट में क्या टूटता है?
5. आपकी सबसे महत्वपूर्ण इकाई के लिए नामित स्टीवर्ड कौन है, और क्या उनके पास वास्तव में काम करने का अधिकार और समय है?
6. जब कोई गोल्डन रिकॉर्ड बदलता है, तो आपके डाउनस्ट्रीम सिस्टम कैसे पता लगाते हैं, और इसके नुकसान पहुँचाने से पहले वे कितने बासी हो सकते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे पठन

• David Loshin, Master Data Management
• Alex Berson and Larry Dubov, Master Data Management and Data Governance
• Dan Power, The Definitive Guide to Master Data Management
• John Talburt, Entity Resolution and Information Quality
• Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
• Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage,” Journal of the American Statistical Association
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
• Ralph Kimball and Margy Ross, The Data Warehouse Toolkit