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