कंसॉलिडेशन बनाम ऑर्केस्ट्रेशन: क्या आपको वाकई कम टूल्स चाहिए?

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

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

कंसॉलिडेशन क्या हल करता है, और क्या नहीं

कंसॉलिडेशन टूल्स की संख्या घटाता है, आमतौर पर एक ऐसी सुइट अपनाकर जो कई कैटेगरीज़ को कवर करती है या ओवरलैपिंग पॉइंट सॉल्यूशंस को खत्म करके। फायदे असली हैं: मैनेज करने के लिए कम वेंडर्स, कम लाइसेंस बर्बादी, कम इंटीग्रेशन पॉइंट्स (जो इंटीग्रेशन टैक्स को घटाता है), और इसका इस्तेमाल करने वाले लोगों के लिए एक ज़्यादा स्टैंडर्डाइज़्ड एक्सपीरियंस।

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

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

ऑर्केस्ट्रेशन इसके बजाय क्या करता है

ऑर्केस्ट्रेशन एक अलग सवाल से शुरू होता है: टूल्स कितनी अच्छी तरह कोऑर्डिनेट करते हैं, और उन्हें बेहतर कोऑर्डिनेट कराने के लिए क्या कमी है? एक ऑर्केस्ट्रेशन लेयर टूल्स के ऊपर बैठती है, उनके डेटा को एक शेयर्ड मॉडल में खींचती है, और उनके बीच एक्शन मूव करती है। स्टैक में चाहे जितने प्रोडक्ट हों, यह एक सिस्टम की तरह व्यवहार करता है।

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

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

सही लीवर चुनना

ये दोनों एक-दूसरे को खारिज नहीं करते, और ज़्यादातर अच्छी स्टैक स्ट्रैटेजीज़ दोनों का इस्तेमाल करती हैं। लेकिन ये अलग-अलग समस्याओं को ठीक करते हैं, इसलिए लीवर को बीमारी से मैच कीजिए।

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

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

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

लक्ष्य कभी कम टूल्स नहीं था

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

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

मुख्य बातें

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

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