टीम को तोड़े बिना स्प्रेडशीट्स से माइग्रेट करना

31 जनवरी 20268 min read

टीम को तोड़े बिना स्प्रेडशीट्स से माइग्रेट करना

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

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

स्प्रेडशीट्स क्यों जीतती हैं, और कहां हारती हैं

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

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

माइग्रेशन का लक्ष्य है वह रखना जो स्प्रेडशीट्स को पसंद करवाता है और वह हटाना जो उन्हें स्केल पर खतरनाक बनाता है।

बदलने से पहले इसे समझें

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

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

यह ऑडिट बेढंगा है। यह वह जगह भी है जहां माइग्रेशन जीते या हारे जाते हैं। यह डेटा हाइजीन ठीक करने का भी एक स्वाभाविक पल है, क्योंकि गंदे डेटा को एक साफ सिस्टम में माइग्रेट करना बस गड़बड़ी को स्थानांतरित करता है और इसे एक बेहतर UI देता है।

धीरे-धीरे, कभी बिग-बैंग नहीं

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

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

एक बार में एक यूज़ केस माइग्रेट करें। उस वर्कफ़्लो से शुरू करें जो सबसे ज़्यादा भरोसा बनाएगा, चाहे यह सबसे दर्दनाक हो, सबसे वैल्यूएबल हो, या बस सबसे आसान हो। पैटर्न साबित करें, फिर आगे बढ़ें।

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

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

यह पॉइंट-टू-पॉइंट इंटीग्रेशंस को अनवाइंड करने जैसा ही डिसिप्लिन है। पानी बहते रहने के दौरान प्लंबिंग बदलें।

जो लोगों ने असल में वैल्यू किया उसे प्रोटेक्ट करें

एक माइग्रेशन जो एक फ्लेक्सिबल स्प्रेडशीट को एक रिजिड सिस्टम से बदलता है जिसे लोग नफरत करते हैं, फेल हो गया है, भले ही हर नंबर परफेक्ट हो। उन गुणों की रक्षा करें जिन्होंने स्प्रेडशीट को भरोसेमंद बनाया।

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

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

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

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

मुख्य बातें

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

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

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.