CRM डेटा गुणवत्ता ऑडिट: सफ़ाई से पहले समस्याएँ मापें

शुरू करने से पहले: डेटा को जो काम करना है, वह चुनें

ऐसे CRM की कल्पना करें जिसमें हजारों संपर्क पूरी तरह भरे हैं, लेकिन बारह सक्रिय सौदों का कोई जिम्मेदार व्यक्ति नहीं है। कुल भराव का स्कोर भरोसेमंद लग सकता है। उन सौदों को सौंपने की कोशिश कर रहा बिक्री प्रबंधक शायद सहमत न हो।

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

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

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

• ब्रिटेन सरकार: डेटा गुणवत्ता के आयाम और उपयोग के अनुरूप गुणवत्ता ↗

1. पात्र रिकॉर्ड तय करें और स्नैपशॉट लें

समूह इतनी स्पष्टता से लिखें कि दूसरा व्यक्ति वही रिकॉर्ड चुन सके। “सौदे” पर्याप्त नहीं है। “ऑडिट की तारीख को 09:00 Europe/Amsterdam पर नीदरलैंड पाइपलाइन में नए ग्राहकों के खुले सौदे, चिह्नित टेस्ट रिकॉर्ड छोड़कर” एक उपयोगी शुरुआत है।

तय करें कि मौजूदा स्नैपशॉट जाँच रहे हैं या किसी अवधि में बने रिकॉर्ड। स्नैपशॉट बताता है कि अभी क्या गलत है। बनने की अवधि वाला समूह बताता है कि प्रक्रिया लगातार दोष बना रही है या नहीं। पूरे ऑडिट में यह अंतर बनाए रखें।

1. व्यावसायिक उपयोग, CRM ऑब्जेक्ट, पाइपलाइन या वर्ग, समय, समय क्षेत्र और बहिष्करण लिखें। जाँच के लिए जरूरी संबंधित ऑब्जेक्ट पहचानें।
2. चयन और अनुमति प्राप्त तारीख वाला एक्सपोर्ट या परिणाम सुरक्षित रखें। स्थिर रिकॉर्ड ID और ऑडिट के जरूरी फ़ील्ड शामिल करें; असंबंधित व्यक्तिगत जानकारी न जुटाएँ।
3. अलग-अलग पात्र ID गिनें। डेटा जोड़ने पर एक सौदे की कई पंक्तियाँ बनती हों तो मापने से पहले हर सौदे की एक पंक्ति रखें या अलग डील ID गिनें।
4. पहुँच की सीमाएँ और गायब इतिहास दर्ज करें। केवल एक टीम के रिकॉर्ड दिखते हों तो परिणाम उसी टीम के समूह का बताएँ।

2. “अच्छे डेटा” को स्पष्ट नियमों में बदलें

वर्कफ़्लो के जरूरी कुछ फ़ील्ड या संबंध चुनें। हर एक के लिए लिखें कि क्या सही है, क्या गलत और क्या वास्तव में लागू नहीं होता। खाली अगली कार्रवाई दोष हो सकती है; “बाद में तय होगा” से भरा फ़ील्ड भी बेकार हो सकता है। दोनों को कैसे गिनेंगे, यह तय करें।

पूर्णता और सहीपन अलग रखें। भरी राशि वैध संख्या हो सकती है, फिर भी हस्ताक्षरित अनुबंध से अलग हो सकती है। सही दिखती तारीख गलत घटना की हो सकती है। जाँच बताए कि वह किस सवाल का जवाब देती है।

1. हर जाँच को ID और सरल नियम दें, जैसे DQ-01: पात्र खुले सौदों का सक्रिय जिम्मेदार व्यक्ति या स्वीकृत कतार अपवाद होना चाहिए।
2. उस नियम का पात्र समूह बताएँ। कंपनियों के सौदों के लिए संबंध की शर्त अलग उपभोक्ता बिक्री प्रक्रिया पर लागू नहीं भी हो सकती है।
3. दोष की शर्त लिखें: जिम्मेदार व्यक्ति गायब या निष्क्रिय, मान सीमा के बाहर या जरूरी संबंध गायब। जहाँ सुधार अलग चाहिए, ये श्रेणियाँ अलग रखें।
4. मापने से पहले प्रक्रिया के जिम्मेदार व्यक्ति से नियम और अपवाद नीति की पुष्टि लें। संस्करण दर्ज करें ताकि बाद के बदलाव दिखें।

• ब्रिटेन सरकार: डेटा गुणवत्ता के आयाम और उपयोग के अनुरूप गुणवत्ता ↗

3. जाँचें चलाएँ और गणना दिखाएँ

हर नियम के लिए प्रभावित पात्र ID गिनें और सभी पात्र ID की गिनती से भाग दें। दोष दर = प्रभावित पात्र रिकॉर्ड ÷ पात्र रिकॉर्ड × 100। प्रतिशत के साथ गिनतियाँ दिखाएँ। कोई पात्र रिकॉर्ड न हो तो “लागू नहीं: शून्य पात्र रिकॉर्ड” लिखें, पूर्ण स्कोर नहीं।

कुल के साथ हर परिणाम के पीछे के ID सुरक्षित रखें। इससे उन्हीं रिकॉर्ड की जाँच और बाद में पुष्टि संभव होगी। माप की तारीख, क्वेरी या फ़िल्टर, नियम का संस्करण और मानवीय निर्णय परिणाम के साथ रखें।

1. सेव किए समूह पर हर जाँच चलाएँ। केवल स्पेस वाले मान और तय अस्थायी मान समान ढंग से सँभालें; अज्ञात मान चुपचाप डिफ़ॉल्ट से न भरें।
2. हर जाँच का एक परिणाम रखें: प्रभावित गिनती, पात्र गिनती, दोष दर और उसे बनाने वाले ID या व्यू।
3. कुछ सफल और विफल रिकॉर्ड देखकर पुष्टि करें कि नियम अपेक्षित ढंग से काम करता है। क्वेरी पूरी तरह दोहराने योग्य होकर भी गलत फ़ील्ड जाँच सकती है।
4. हर समस्या की दर अलग रखें। किसी भी दोष वाले रिकॉर्ड बताने के लिए प्रभावित ID का संयुक्त समूह लें और हर रिकॉर्ड एक बार गिनें।

4. सहीपन की पुष्टि करें और संभावित डुप्लिकेट जाँचें

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

किसी खास पैटर्न को समझने के लिए जाँच वाला नमूना चुनें। व्यापक त्रुटि दर का अनुमान चाहिए तो यादृच्छिक नमूना या संबंधित समूहों में दस्तावेज़ित चयन लें। सही नमूना आकार जरूरी सटीकता और विश्वास पर निर्भर है; “20 रिकॉर्ड जाँचें” का कोई सार्वभौमिक नियम नहीं।

1. हर सहीपन जाँच का आधिकारिक स्रोत और उसे सत्यापित करने का समय लिखें। दूसरा डेटाबेस बाहरी है, केवल इसलिए उसे सही न मानें।
2. हर जाँचे रिकॉर्ड में मिलान, अंतर या सत्यापन असंभव होने की स्थिति और साक्ष्य लिखें। सत्यापित न हो सकने वाले रिकॉर्ड अलग रखें, सही न मानें।
3. उस इकाई के उपलब्ध पहचानकर्ताओं से संभावित डुप्लिकेट समूह बनाएँ। तुलना के मान एक समान ढंग से सामान्यीकृत करें और समीक्षा के लिए मूल मान सुरक्षित रखें।
4. हर संभावित डुप्लिकेट की पहचान, संबंध और तय रिकॉर्ड मॉडल की तुलना करें। समान नाम अकेले दोहराव साबित नहीं करते; कई सहायक कंपनियाँ वैध रूप से एक ब्रांड या डोमेन साझा कर सकती हैं।
5. पहचान की पुष्टि के बाद ही समीक्षा का परिणाम और बचाए जाने वाला रिकॉर्ड लिखें। मर्ज करने का निर्णय और उसे लागू करना अलग रखें।

5. हर दोष CRM में कहाँ से आता है, पता करें

प्रभावित रिकॉर्ड को बनने के स्रोत, अपडेट स्रोत, इम्पोर्ट बैच, टीम और समय के अनुसार बाँटें। हर पात्र समूह की दोष दर तुलना करें, केवल दोषों की गिनती नहीं। सबसे अधिक रिकॉर्ड वाले स्रोत में भरोसेमंद प्रक्रिया होने पर भी सबसे अधिक दोष हो सकते हैं।

फिर उदाहरणों को मूल तक ले जाएँ। जरूरी फ़ील्ड ऐसी जानकारी माँग सकता है जो तब उपलब्ध ही नहीं होती। इंटीग्रेशन गलत विकल्प जोड़ सकता है। टीम गतिविधि दूसरे सिस्टम में लिख सकती है। स्क्रीन पर वही खाली सेल दिखे, फिर भी इन कारणों के सुधार अलग हैं।

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

6. क्या सुधारना है चुनें और सुधार परिभाषित करें

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

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

1. हर समस्या के लिए प्रभावित काम, गिनती, परिणाम, विश्वास, तात्कालिकता, निर्भरताएँ और मेहनत लिखें। बिना साक्ष्य के राजस्व नुकसान का अनुमान प्राथमिकता के तर्क में न जोड़ें।
2. सही मान कैसे मिलेगा, तय करें। सत्यापित स्रोत या जिम्मेदार व्यक्ति की समीक्षा लें; भराव का प्रतिशत बढ़ाने के लिए संभावित मान गढ़ें नहीं।
3. अपवाद और अज्ञात मान कैसे सँभालेंगे, लिखें। वैध अपवाद स्पष्ट और समीक्षा योग्य रहे, छिपे फ़िल्टर से गायब न हो।
4. सुधार का सबसे छोटा समीक्षा योग्य और जाँचा जा सकने वाला बैच चुनें। डुप्लिकेट मर्ज करने से पहले संबंध, इतिहास और आगे के सिस्टम कैसे सँभालेंगे, तय करें।

• HubSpot: रिकॉर्ड मर्ज करने का व्यवहार और सीमाएँ ↗

7. सुधार जाँचें और मूल माप दोहराएँ

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

सुधार से पहले और बाद में समान समूह तथा नियम संस्करण की तुलना करें। समूह बदले तो स्पष्ट बताएँ। नए सही रिकॉर्ड जुड़ने पर केवल घटा प्रतिशत यह नहीं दिखाता कि कोई पुराना दोष सुधरा।

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

8. जाँचों को काम की दिनचर्या में शामिल करें

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

प्रक्रिया की जरूरत और परिणाम के आधार पर सीमाएँ तय करें। “95% सही” जैसा साझा लक्ष्य छोटे लेकिन महत्वपूर्ण समूह का गंभीर दोष छिपा सकता है। परिभाषा बदले तो पुराना परिणाम रखें और बताएँ कि अगला सीधे तुलना योग्य क्यों नहीं है।

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