गो-टू-मार्केट टीमों में टूल स्प्रॉल की छिपी हुई कॉस्ट

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

टूल स्प्रॉल वह है जो कुछ सालों बाद ये छिपी हुई कॉस्ट्स दिखती हैं। कोई भी जानबूझकर स्टैक को अनमैनेजेबल नहीं बनाता। यह उचित निर्णयों के ज़रिए रेंगता है, एक बार में एक टीम, जब तक ऑर्ग दर्जनों ओवरलैपिंग ऐप्स नहीं चला रहा होता, कोई नहीं जानता आधों का मालिक कौन है, और रेप्स हर दिन का एक हिस्सा चीज़ों में लॉगिन और लॉगआउट करने में बिताते हैं।

स्प्रॉल एक लक्षण है

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

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

पांच छिपी हुई कॉस्ट्स

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

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

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

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

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

इसे आंकने का एक मोटा तरीका

आपको किसी कंसल्टिंग एंगेजमेंट की ज़रूरत नहीं है। एक बैक-ऑफ-एनवलप वर्जन ठीक काम करता है।

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

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

टूल्स जोड़ना प्रोग्रेस जैसा क्यों महसूस होता है

एक टूल खरीदना निर्णायक महसूस होता है। यह एक विज़िबल गैप को एड्रेस करता है और एक डेमो के साथ आता है जो शानदार दिखता है। लेकिन हर नया टूल एक ऐसे नेटवर्क में एक नोड है जिसकी जटिलता इसकी कैपेबिलिटी से तेज़ी से बढ़ती है।

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

तो स्प्रॉल का जवाब शायद ही कभी "एक बेहतर टूल खरीदो" होता है। यह बदलने के बारे में है कि जो टूल्स आप रखते हैं वे साथ में कैसे काम करते हैं। यह खरीदारी से ज़्यादा ऑर्केस्ट्रेशन का सवाल है।

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

अगर स्प्रॉल आप पर रेंग आया है, तो छोटे और ठोस से शुरू करें।

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

मुख्य बातें

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

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