हर एट्रिब्यूट के लिए सच का एक स्रोत

🌐 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 कोर्स का अध्याय 6। हर मॉड्यूल अपने आप में पूरा है। अगला: मास्टर डेटा के चार तरीके

यह मॉड्यूल किस सवाल का जवाब देता है: “सच का एक ही स्रोत” का असल में मतलब क्या है?

एक वाक्य मैं लगातार सुनता हूँ: “हमें सच का एक ही स्रोत चाहिए।” ठीक है। किस चीज़ के लिए? ग्राहक के लिए? यह काफ़ी स्पष्ट नहीं है। एक account लीजिए। ग्राहक के नाम, बिलिंग पते, क्रेडिट लिमिट, account executive, सपोर्ट टियर, मार्केटिंग पसंद का मालिक कौन है? ये जवाब एक ही सिस्टम की ओर इशारा नहीं करते। कानूनी नाम, बिलिंग पता और क्रेडिट स्टेटस शायद ERP नियंत्रित करे; संबंध का मालिक और सेल्स एट्रिब्यूट Salesforce; और consent कोई दूसरा प्लेटफ़ॉर्म। इसलिए जब कोई मुझसे कहता है, “ग्राहक के लिए Salesforce ही हमारा सच का एक स्रोत है,” तो मेरा अगला सवाल होता है: कौन-सा सच?

सच एट्रिब्यूट का होता है

मास्टर डेटा का पहला सिद्धांत यह है: अधिकार हर एट्रिब्यूट के लिए तय होता है, हर रिकॉर्ड के लिए नहीं। एक account Salesforce में रह सकता है, बिना इसके कि Salesforce उसके हर फ़ील्ड के लिए आधिकारिक हो। एक रिकॉर्ड पर सात फ़ील्ड, दो अधिकार:

एट्रिब्यूट	आधिकारिक सिस्टम
कानूनी नाम, बिलिंग पता, ERP ग्राहक ID, क्रेडिट लिमिट	ERP
Account executive, strategic account flag, success tier	Salesforce

एक रिकॉर्ड; सच बँटा हुआ है। यह सामान्य है। “System of record = Salesforce” इसका वर्णन नहीं करता। एक अधिकार-मॉडल करता है।

कहाँ बनता है, कहाँ एडिट होता है, कहाँ संदर्भित होता है, और कितनी तेज़ी से?

जब मैं मास्टर डेटा पढ़ाता हूँ, तो हर अहम डेटा के लिए बार-बार इन्हीं सवालों पर लौटता हूँ: यह कहाँ बनता है, कहाँ एडिट होता है, कहाँ संदर्भित होता है, और इसके बदलने की latency क्या है? ये आर्किटेक्चर को तेज़ी से सामने ला देते हैं। (पहले तीन सवाल आप अध्याय 4 में डेटा के प्रकार छाँटते हुए देख चुके हैं; असली काम वे यहाँ करते हैं।)

एक asset लीजिए। एक ग्राहक तीन साइकिलें ऑर्डर करता है। Salesforce के पास opportunity और उसके लाइन आइटम हैं, और ऑर्डर ERP में जाता है। ERP उसे पूरा करता है, और asset वहीं बनते हैं: तीन साइकिलें, तीन सीरियल नंबर, जो Salesforce को वापस भेजे जाते हैं। महीनों बाद ग्राहक उनमें से एक के बारे में कॉल करता है, और सपोर्ट एक case में उस asset को संदर्भित करता है। अब किसी को एक एट्रिब्यूट ठीक करना है। Salesforce कौन-से एडिट कर सकता है, और कौन-से उस ERP के हैं जिसने उन्हें बनाया? और जब ERP किसी को बदलता है, तो Salesforce को कितनी जल्दी पता चलना चाहिए? एक asset, चार सवाल, और हर फ़ील्ड के लिए जवाब एक-से नहीं हैं।

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

Latency भी सच का हिस्सा है। ERP सुबह 10 बजे एक ग्राहक का क्रेडिट स्टेटस बदलता है; Salesforce उसे रात में सिंक करता है; दोपहर 3 बजे एक rep Salesforce देखता है। क्या मान गलत है? वह पुराना (stale) है। अगर मान साल में एक बार बदलता है और एक दिन की देरी से कुछ नहीं बिगड़ता, तो रात का सिंक ठीक है। अगर वही तय करता है कि आप आज एक मिलियन डॉलर का ऑर्डर लेंगे या नहीं, तो ठीक नहीं है। अधिकार बताता है कि सच कहाँ से आता है; latency बताती है कि दूसरों को उसके बदलने का पता कितनी जल्दी चलना चाहिए। दो अलग फ़ैसले।

System of Record, Engagement, Reference

अध्याय 4 की शब्दावली यहाँ मदद करती है। एक system of record (रिकॉर्ड का सिस्टम) आधिकारिक संस्करण बनाए रखता है। एक system of engagement वह है जहाँ लोग उसके साथ काम करते हैं। एक system of reference वह डेटा देता है जिसे कोई दूसरा सिस्टम इस्तेमाल करता है, पर जिसका मालिक नहीं होता। Salesforce ग्राहक संबंध के लिए system of engagement हो सकता है, जबकि ERP उसके कानूनी और वित्तीय एट्रिब्यूट के लिए system of record बना रहता है। यह आर्किटेक्चर की कमज़ोरी नहीं है; यही तो आर्किटेक्चर है। गलती यह दिखावा करना है कि एक ही सिस्टम को सब कुछ का मालिक होना चाहिए, ताकि डायग्राम सरल दिखे।

हाइब्रिड गोल्डन रिकॉर्ड

इससे “गोल्डन रिकॉर्ड” का मतलब बदल जाता है। अध्याय 5 ने खराब डेटा को बाहर रखने के दौरान यह विचार पेश किया था; यहाँ यह डिज़ाइन का दिल है। लोग एक जादुई रिकॉर्ड की कल्पना करते हैं जिसका हर फ़ील्ड एक ही जगह मास्टर होता है। कभी-कभी डिज़ाइन यही होता है। Salesforce पर, ज़्यादातर मुझे एक हाइब्रिड दिखता है: account का एक हिस्सा कहीं और मास्टर होता है और अंदर कॉपी किया जाता है (कानूनी नाम, ERP ग्राहक नंबर, बिलिंग पता, क्रेडिट स्टेटस), और एक हिस्सा सिर्फ़ इसलिए मौजूद है क्योंकि Salesforce को उसकी ज़रूरत है (account executive, opportunity रणनीति, success tier, संबंध के नोट्स)। ERP के फ़ील्ड इसलिए आते हैं ताकि लोग उनका इस्तेमाल कर सकें। Salesforce के फ़ील्ड कभी वापस नहीं जाते, क्योंकि ERP को उनकी परवाह नहीं। बिल्कुल ठीक, जब तक सबको पता हो कि कौन-सा क्या है।

अधिकार को दिखने लायक बनाएँ

इसलिए मैं बाहरी अधिकार को स्कीमा में साफ़ दिखाता हूँ। अगर SAP किसी फ़ील्ड को नियंत्रित करता है, तो उसे एक prefix मिलता है: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name। यह अध्याय 4 के erp_ prefix वाला ही विचार है। जब अधिकार खास और स्थिर हो तो सिस्टम का नाम इस्तेमाल करें, और जब आज के vendor से ज़्यादा मतलब मायने रखता हो तो एक सामान्य prefix। मकसद यह है कि छह महीने बाद मॉडल पढ़ने वाला कोई भी देख सके: यह बस एक और Salesforce फ़ील्ड नहीं है; इस मान का मालिक कोई दूसरा सिस्टम है। लोगों को इंटीग्रेशन को उलटा खोलकर अधिकार दोबारा खोजने पर मजबूर न करें।

अधिकार-मानचित्र बनाएँ

अहम मास्टर डेटा के लिए मुझे एक अधिकार-मानचित्र (authority map) चाहिए: हर मुख्य एट्रिब्यूट के लिए, उसे कौन बनाता है, बिज़नेस फ़ैसले का मालिक कौन है, कौन-सा सिस्टम आधिकारिक है, और कौन या क्या उसे बदल सकता है। चार अलग सवाल:

एट्रिब्यूट	किसने बनाया	बिज़नेस मालिक	आधिकारिक सिस्टम	कौन बदल सकता है
कानूनी नाम	फ़ाइनेंस	फ़ाइनेंस	ERP	फ़ाइनेंस प्रोसेस
क्रेडिट लिमिट	फ़ाइनेंस	फ़ाइनेंस	ERP	क्रेडिट टीम
Account executive	सेल्स ऑपरेशंस	सेल्स	Salesforce	सेल्स मैनेजमेंट
सपोर्ट टियर	सर्विस ऑपरेशंस	सर्विस	Salesforce	सर्विस मैनेजमेंट
Consent (सहमति)	ग्राहक	प्राइवेसी	Consent प्लेटफ़ॉर्म	ग्राहक, एक मंज़ूर प्रोसेस

ध्यान दें कि बिज़नेस मालिक और आधिकारिक सिस्टम एक ही चीज़ नहीं हैं। नीति का मालिक कोई सिस्टम नहीं होता; लोग होते हैं। सिस्टम नतीजे को स्टोर करता है और लागू करता है। यह फिर से अध्याय 5 है: मालिक नीति तय करते हैं; आर्किटेक्ट उसे लागू करते हैं।

Click to enlarge

एक ग्राहक। कई एट्रिब्यूट। हर एक के लिए एक अधिकार।

जीवनचक्र के साथ अधिकार बदलता है

एक rep ऐसे prospect से मिलता है जिसके बारे में ERP ने कभी सुना ही नहीं, और Salesforce में account बनाता है। उस समय नाम, पता, contacts और qualification के लिए Salesforce आधिकारिक है। Prospect ग्राहक बन जाता है; ERP आधिकारिक ग्राहक बनाता है और ग्राहक नंबर, कानूनी नाम, बिलिंग पता और क्रेडिट तय करता है। अधिकार खिसक गया। Salesforce पहले गलत नहीं था; जीवनचक्र बदल गया। यह अध्याय 5 का अस्थायी-से-नियंत्रित (provisional-to-governed) पैटर्न है: conversion से पहले prospect का मालिक Salesforce है; उसके बाद नियंत्रित एट्रिब्यूट का मालिक ERP है, और Salesforce अपने एट्रिब्यूट का मालिक बना रहता है। इसलिए “account का मालिक कौन-सा सिस्टम है?” एक कमज़ोर सवाल है। पूछें: जीवनचक्र के इस मोड़ पर, इस एट्रिब्यूट का मालिक कौन-सा सिस्टम है?

कॉपी अधिकार नहीं है

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

भरोसे के लिए सिर्फ़ मान काफ़ी नहीं

“बिलिंग पता: 123 Main Street।” क्या आपको इस पर भरोसा करना चाहिए? मुझे भरोसे के संकेत चाहिए: यह कहाँ से आया, आखिरी बार कब पुष्टि हुई, किस सिस्टम ने दिया, और किसने या किस चीज़ ने इसे आखिरी बार बदला: एक व्यक्ति, एक इंटीग्रेशन, एक एजेंट? अब ERP कहता है 123 Main Street, Salesforce कहता है 125, और एक पार्टनर फ़ाइल कहती है “123 Main St., Suite 200।” कौन-सा सही है? “सबसे नया वाला इस्तेमाल करें” जवाब न दें। हो सकता है। लेकिन “सबसे नया” अपने आप में एक नियम है, जो मान लेता है कि जिसने आखिरी बार बदला वही जीतने का हक़दार है। यह सच हो सकता है, या भयानक। मॉड्यूल 3 इसी से निपटता है। भरोसा अधिकार और उद्गम (provenance) से आता है, किसी भरे हुए फ़ील्ड को ढूँढ लेने से नहीं।

Steve Trucking: यह सच किसका है?

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

Click to enlarge

एक डिलीवरी, दो अधिकार।

डेटा कहाँ रहता है और उसके सच का मालिक कौन है, ये अलग सवाल हैं। Salesforce ERP ग्राहक नंबर को रख सकता है बिना उसका मालिक हुए; Snowflake डिलीवरी स्टेटस रख सकता है बिना उसका ऑपरेशनल मास्टर हुए; एक customer data platform पहचानों को एकीकृत कर सकता है बिना हर एट्रिब्यूट का मालिक हुए। एक एजेंट तीनों को पढ़ सकता है, और इससे एजेंट को यह तय करने का हक़ बिल्कुल नहीं मिलता कि सच क्या है।

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

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

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

सच के एक स्रोत का मतलब एक org, एक ERP, एक MDM प्लेटफ़ॉर्म या एक विशाल रिकॉर्ड नहीं है। इसका मतलब है कि हर नियंत्रित जानकारी के लिए आर्किटेक्चर बता सके कि आधिकारिक मान कहाँ है, और इसी वजह से हर दूसरा सिस्टम जानता है कि उसे कैसे व्यवहार करना है। यह सच का एक स्रोत नहीं है। यह सच का एक आर्किटेक्चर है।

और जानें

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