डेटा साइलोज़ एक रेवेन्यू समस्या हैं, IT समस्या नहीं

जब कोई रेवेन्यू लीडर कहता है कि डेटा गड़बड़ है, तो ज़्यादातर कंपनियां समस्या को IT या RevOps के पास भेज देती हैं और इसे हाइजीन के तहत फाइल कर देती हैं। फील्ड्स साफ करो, रिकॉर्ड्स डीड्यूप करो, सिंक ठीक करो। यह एक गलत निदान है। साइलोज़ सिर्फ उन लोगों के लिए एक झुंझलाहट नहीं हैं जो सिस्टम्स मेंटेन करते हैं। वे रेवेन्यू को दबाते हैं, डिसीज़न्स को विकृत करते हैं, और पूरे गो-टू-मार्केट मोशन को धीमा करते हैं। वे CRO के एजेंडे पर होने चाहिए, किसी बैकलॉग टिकट में नहीं।

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

साइलो क्या है

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

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

साइलोज़ आपको रेवेन्यू में कैसे कॉस्ट करते हैं

नुकसान स्पेसिफिक और ट्रेसेबल है।

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

गड़बड़ हैंडऑफ्स। जब सेल्स किसी कस्टमर को बिना किसी कॉन्टेक्स्ट के CS को सौंपता है, तो कस्टमर इसे तुरंत महसूस करता है। वे खुद को दोबारा समझाते हैं, भरोसा घटता है, और एक्सपेंशन मुश्किल हो जाता है। जो एक रिलेशनशिप होनी चाहिए वह कोल्ड रीस्टार्ट्स की एक सीरीज़ बन जाती है।

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

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

"बस इंटीग्रेट कर लो" क्यों काम नहीं करता

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

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

इसे लीडरशिप की समस्या बनाना

अगर साइलोज़ एक रेवेन्यू समस्या हैं, तो उन्हें ओन करना एक रेवेन्यू लीडरशिप का काम है। इसका मतलब है कुछ चीज़ें।

इस पर एक नंबर लगाएं। स्पेसिफिक छूटी हुई अपॉर्चुनिटीज़, धीमे हैंडऑफ्स, और फोरकास्ट डिस्प्यूट्स को उनके सिलोड कारणों से जोड़ें ताकि समस्या के साथ एक कॉस्ट जुड़ी हो और यह ध्यान के लिए मुकाबला कर सके।

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

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

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

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

मुख्य बातें

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

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