RevOps डेटा हाइजीन: ऑर्केस्ट्रेशन की अनदेखी फाउंडेशन

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

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

डेटा खराब होने के चार तरीके

रेवेन्यू डेटा अनुमानित तरीकों से खराब होता है, और हर एक का अलग समाधान है, इसलिए इन्हें नाम देना मददगार है।

डुप्लिकेशन। "Acme," "Acme Inc," और "Acme Corporation" सब मौजूद हैं क्योंकि तीन टूल्स ने स्वतंत्र रूप से अकाउंट बनाया और कुछ भी उन्हें रिज़ॉल्व नहीं करता। पाइपलाइन काउंट बढ़ जाते हैं, एक्टिविटी हिस्ट्री तीन तरह से बंट जाती है, और कोई एक रिकॉर्ड आपको कुछ नहीं बताता।

अधूरापन। जिन फील्ड्स की आपको एनालिसिस के लिए ज़रूरत है वे खाली हैं। अगर 30% अवसरों में कोई लीड सोर्स नहीं है, तो सोर्स-बेस्ड अट्रिब्यूशन 30% अनिश्चित नहीं है। यह बेकार है, क्योंकि आपको यह जानने का कोई तरीका नहीं है कि गायब 30% उस 70% जैसा दिखता है भी या नहीं जो आप देख सकते हैं।

असंगति। एक ही कॉन्सेप्ट हर सिस्टम में अलग तरह से एनकोड किया गया है। यहां "Closed Won," वहां "Won," तीसरे में "6 - Closed"। उन सिस्टम में हर जॉइन रो को ड्रॉप या मिसकाउंट करता है, और यह चुपचाप करता है।

पुरानापन। फील्ड एक बार सही थी। चैंपियन चला गया, टियर बदल गया, और किसी ने अपडेट नहीं किया। पुराना डेटा चारों में सबसे खतरनाक है क्योंकि यह साफ दिखता है। फील्ड में एक वैल्यू है। बस वह गलत है।

ज़्यादातर "हमारे नंबर मेल नहीं खाते" वाली आग बुझाने की कवायदें इनमें से किसी एक तक जाती हैं। यह पता लगाना कि कौन सी, आधा काम है।

क्लीनअप टिकते नहीं

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

तो असली काम उन पॉइंट्स पर होता है जहां डेटा एंटर होता है और सिस्टम के बीच मूव करता है।

राइट टाइम पर वैलिडेट करें। खराब डेटा को तब रिजेक्ट या फ्लैग करें जब यह बनता है, महीनों बाद नहीं। ज़रूरी फील्ड्स, फॉर्मेट कंस्ट्रेंट्स, और लागू पिकलिस्ट ज़्यादातर अधूरेपन और असंगति को दरवाज़े पर ही रोक देते हैं।

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

लगातार मॉनिटर करें। पूर्णता, डुप्लिकेशन, और फ्रेशनेस को चालू मेट्रिक्स के रूप में अलर्ट के साथ ट्रैक करें, जैसे आप अपटाइम देखते हैं। एक डैशबोर्ड जो कहता है "12% खुले अवसरों में कोई अगला कदम नहीं है" एक अदृश्य समस्या को ऐसी चीज़ में बदल देता है जिसका किसी को जवाब देना पड़े।

समय-समय पर क्लीनअप से एक स्थायी सिस्टम की ओर बढ़ना शायद सबसे उपयोगी बदलाव है जो ज़्यादातर RevOps टीमें कर सकती हैं, और यह ज़्यादातर इस बारे में है कि हाइजीन लॉजिक कहां रहता है न कि यह कितना स्मार्ट है।

किसके लिए काफी साफ

परफेक्ट डेटा एक कल्पना है, और इसका पीछा करना खुद एक फेलियर मोड है। उपयोगी सवाल यह है कि क्या डेटा उस फैसले के लिए काफी साफ है जिसे यह फीड करता है। स्टैंडर्ड को कंज़्यूमर पर निर्भर होना चाहिए।

एग्ज़ीक्यूटिव फोरकास्टिंग को फील्ड्स के एक संकीर्ण सेट (स्टेज, अमाउंट, क्लोज़ डेट) पर उच्च सटीकता चाहिए और बाकी जगह गड़बड़ी सहन कर सकती है।

ऑटोमेटेड रूटिंग और राइट-बैक को सबसे ज़्यादा संगति चाहिए, क्योंकि मशीनें जजमेंट लागू नहीं करतीं। एक गलत-केस पिकलिस्ट वैल्यू रूल तोड़ देती है और किसी को पता नहीं चलता जब तक कोई डील गलत रेप को रूट नहीं हो जाती। राइट-बैक लेयर ठीक इसी वजह से अपस्ट्रीम असंगति को माफ नहीं करती।

अट्रिब्यूशन को टचपॉइंट्स और आइडेंटिफायर्स पर पूर्णता चाहिए, क्योंकि गैप पूरे मॉडल को विकृत कर देते हैं। अट्रिब्यूशन स्पाइन इस पर पूरी तरह निर्भर करती है।

इन थ्रेशोल्ड को लिख लेना आपको ऐसी एनालिटिक्स शिप करने से रोकता है जिसे डेटा सपोर्ट नहीं कर सकता, और ऐसी फील्ड्स को पॉलिश करने से रोकता है जिन्हें कोई फैसला कभी नहीं पढ़ता।

कहां से शुरू करें

अगर आप एक गड़बड़ इंस्टेंस देख रहे हैं, तो लीवरेज के हिसाब से सीक्वेंस करें।

साफ करने से पहले इंस्ट्रूमेंट करें। पहले पूर्णता और डुप्लिकेशन मेट्रिक्स खड़ी करें ताकि आप प्रगति माप सकें और किसी को दिखा सकें कि काम ने क्या हासिल किया।

बैकलॉग से पहले इनटेक ठीक करें। नई गंदगी को अंदर आने से रोकना पुरानी गंदगी को साफ करने से ज़्यादा मायने रखता है, क्योंकि अगर इनटेक अभी भी खुला है तो साफ किया गया बैकलॉग फिर से गंदा हो जाता है।

सिस्टम में पिकलिस्ट और ज़रूरी फील्ड्स को स्टैंडर्डाइज़ करें ताकि एक ही कॉन्सेप्ट की हर जगह एक ही एनकोडिंग हो। यह सबसे सस्ती जीत है जिसका सबसे व्यापक डाउनस्ट्रीम फायदा है।

और इसे एक ओनर दें। बिना ओनर वाली डेटा क्वालिटी का कोई भविष्य नहीं है। एक नामित व्यक्ति या टीम जो हाइजीन मेट्रिक्स के लिए जवाबदेह हो, आपके खरीदे किसी भी टूल से ज़्यादा वैल्यू रखती है।

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

मुख्य बातें

• खराब डेटा चार तरह का होता है: डुप्लिकेट, खाली फील्ड्स, असंगत एनकोडिंग, और पुरानी वैल्यू। हर एक को अलग समाधान चाहिए, इसलिए एक्ट करने से पहले डायग्नोज़ करें।
• त्रैमासिक क्लीनअप टिकते नहीं। हाइजीन लॉजिक को राइट टाइम पर और इनजेशन पर रखें, और इसे अपटाइम की तरह मॉनिटर करें।
• एंटिटी को एक बार, शेयर्ड लेयर पर रिज़ॉल्व करें, बजाय इसके कि हर टूल अपने तरीके से डीड्यूप करे।
• "साफ" कंज़्यूमर पर निर्भर करता है। फोरकास्टिंग को सटीकता चाहिए, ऑटोमेशन को संगति, अट्रिब्यूशन को पूर्णता।
• मुश्किल हिस्सा संगठनात्मक है। पहले इंस्ट्रूमेंट करें, इनटेक बंद करें, स्टैंडर्डाइज़ करें, और एक ओनर दें।

Revnewo जैसे ऑर्केस्ट्रेशन प्लेटफॉर्म उतने ही अच्छे हैं जितना वह कैनोनिकल डेटा जिस पर वे चलते हैं। ज़्यादा सोफिस्टिकेटेड मॉडलों में निवेश करने से पहले, यह जांचना उचित है कि क्या फाउंडेशन उन्हें संभाल सकती है।