OD र ट्यालेन्ट प्लेटफर्मको व्यावसायिक प्रस्ताव: सफ्टवेयर होइन, निर्णय बेच्नुहोस्

संगठनात्मक विकास र ट्यालेन्ट सफ्टवेयरका धेरैजसो व्यावसायिक प्रस्ताव बैठकको पहिलो दस मिनेटमै हार्छन्, र एउटै कारणले। तिनले सफ्टवेयर वर्णन गर्छन्: सुविधा, मोड्युल, इन्टिग्रेसन, प्रति प्रबन्धक बचत हुने घण्टा। वरिष्ठ नेतृत्वले नरम सुनिने र ढिलो आइपुग्ने फाइदासहितको नयाँ लागत सुन्छ। स्वीकृत हुने प्रस्तावहरू उल्टो तरिकाले बनाइन्छन्। ती नेतृत्वले पहिल्यै महसुस गरिरहेको एउटा महँगो, दोहोरिने संगठनात्मक समस्याबाट सुरु हुन्छन्, त्यो समस्याले कति खर्च गराउँछ देखाउँछन्, र प्लेटफर्मलाई त्यसको मूल्य तिर्न बन्द गर्ने सबैभन्दा सस्तो विश्वसनीय उपायका रूपमा प्रस्तुत गर्छन्। अनि ती बजेट माग्नुअघि पाइलट माग्छन्।

हामी यो कुराकानीका दुवै पक्षमा बसेका छौँ, HR र रणनीति नेताहरूलाई प्रस्ताव बनाउन सघाउँदै र तिनमाथि निर्णय गर्ने नेतृत्व टोलीहरूको सामुन्ने बस्दै। हामी हरेक पटक एउटा असहज सल्लाह दिन्छौँ: प्लेटफर्मले कुन निर्णय बदल्नेछ भन्ने नाम लिन सक्नुहुन्न भने, तपाईंले त्यो किन्नु हुँदैन। त्यसमा हाम्रो किन्नु पनि पर्छ।

«तपाईंले यसले के गर्छ भन्नुभयो, के बदलिन्छ भन्नुभएन»

करिब तीन सय कर्मचारी भएको साउदी अरबको एउटा कम्पनीका HR निर्देशकले ट्यालेन्ट र संगठनात्मक विकास प्लेटफर्मका लागि व्यावसायिक प्रस्ताव तयार गर्न धेरै हप्ता बिताए। त्यो तीस स्लाइडको थियो: चार विक्रेताको सुविधा तुलना, कार्यसम्पादन समीक्षा र रिपोर्टिङमा बचत हुने अनुमानित घण्टा, विक्रेताका अंकबाट बनाइएको लगानीको प्रतिफल गणना।

प्रमुख वित्त अधिकृतले करिब दस मिनेटमै त्यसलाई अस्वीकार गरे। HR निर्देशकको मनमा बसेको कुरा कारण थियो: «तपाईंले यसले के गर्छ भन्नुभयो। के बदलिन्छ, वा कसले बदल्छ भन्नुभएन।»

दोस्रो प्रयास एउटा स्लाइड थियो। केही महिनाअघिको नेतृत्व अफसाइटमा प्रमुख कार्यकारीले वर्षका तीन रणनीतिक पहल अड्किएको र तिनको मालिक को हो कसैले भन्न नसकेको गुनासो गरेका थिए। नयाँ प्रस्तावले त्यो समस्याको नाम लियो, तीनमध्ये एउटा पहलबाट मात्र ढिलो हुने आम्दानी अनुमान गर्‍यो, नेतृत्व टोलीले प्लेटफर्म प्रयोग गरेर ती तीन पहलको स्वामित्व तोक्ने र ट्र्याक गर्ने नब्बे दिनको पाइलट प्रस्ताव गर्‍यो, र पाइलटले पहिल्यै सहमति गरिएको मापन पूरा गरे मात्र रकम माग्यो। यो उही बैठकमा स्वीकृत भयो।

एक-निर्णय व्यावसायिक प्रस्ताव

दोस्रो प्रयासपछाडिको संरचनाका पाँच भाग छन्, र यसले सफ्टवेयर मात्र होइन, झन्डै कुनै पनि संगठनात्मक लगानीका लागि काम गर्छ।

1. समस्या। नेतृत्वले पहिल्यै महसुस गरेको एउटा नाम दिइएको, दोहोरिने, महँगो संगठनात्मक समस्या, सम्भव भए उनीहरूकै शब्दमा। अड्किएका पहल, अस्पष्ट निर्णय अधिकार, कुनै महत्त्वपूर्ण टोलीबाट पछुतो लाग्ने बहिर्गमन, सफल नभएको पुनर्संरचना। समस्या अस्तित्वमा छ भनी नेतृत्वले पहिल्यै विश्वास गर्दैन भने कुनै पनि व्यावसायिक प्रस्तावले उनीहरूलाई मनाउँदैन; बरु त्यहीँबाट सुरु गर्नुहोस्।
2. केही नगर्दाको लागत। समस्या जारी रहे त्यसले कति खर्च गराउँछ भन्ने दायरामा अनुमान, नेतृत्वले पहिल्यै प्रयोग गर्ने शब्दमा: ढिलो आम्दानी, गुमेका सम्झौता, प्रतिस्थापन लागत, एस्केलेसनमा बित्ने व्यवस्थापनको समय। संयमित र विश्वसनीय अनुमान ठूलो र विवादित अनुमानभन्दा राम्रो हुन्छ।
3. परिवर्तन। कुन निर्णय वा व्यवहार फरक हुनेछ, र कसले फरक तरिकाले गर्नेछ। धेरैजसो प्रस्तावले छोड्ने भाग यही हो, र कथाका CFO ले मागेको भाग पनि यही हो। सफ्टवेयरले आफैँ केही बदल्दैन; त्यसलाई प्रयोग गरेर फरक निर्णय गर्ने मानिसहरूले बदल्छन्।
4. प्रमाण। वास्तविक समस्यामा, जसका निर्णय बदलिनुपर्ने हो ती मानिसहरूसँग, सुरु हुनुअघि सहमति गरिएको मापनसहित, छोटो र समयसीमाभित्रको पाइलट।
5. माग। पाइलटको नतिजासँग जोडिएको चरणबद्ध प्रतिबद्धता, आन्तरिक समयसहित पूरा लागत उल्लेख गरिएको, र काम नगरे रोक्ने स्पष्ट तरिकासहित।

यसरी बनाइएको प्रस्ताव प्रायः एक पृष्ठभन्दा छोटो हुन्छ। त्यो कमजोरी होइन; त्यही कुराले त्यो महिना अरू चालीसवटा निर्णय गर्नुपर्ने नेतृत्व टोलीका लागि यसलाई पढ्न योग्य बनाउँछ।

अब भिन्न मत

ROI प्रतिशतबाट सुरु नगर्नुहोस्। सफ्टवेयरको व्यावसायिक प्रस्तावमा नेतृत्वले सबैभन्दा कम भरोसा गर्ने भाग यही हो, किनभने त्यो विक्रेताबाट आएको हो भनी उनीहरूलाई थाहा हुन्छ, र यसले छलफललाई समस्याबाट अंकपछाडिका मान्यताहरूतिर सार्छ। नेतृत्वले पहिल्यै विश्वास गर्ने लागतको सामान्य अनुमान उनीहरूले आस्थाका भरमा स्वीकार्नुपर्ने ठूलो प्रतिफलभन्दा धेरै बढी प्रभावकारी हुन्छ।

चाहिनेभन्दा कम माग्नुहोस्। पाइलटसहितको चरणबद्ध प्रतिबद्धता ठूलो वार्षिक सम्झौताभन्दा स्वीकृत गर्न सजिलो हुन्छ, र यसले नेतृत्वले जवाफ दिइरहेको प्रश्नलाई «के यो पैसाको लायक छ?» बाट «के यो नब्बे दिनको लायक छ?» मा बदल्छ। पाइलटले काम गर्‍यो भने, दोस्रो स्वीकृति पहिलो हुने थियोभन्दा धेरै सजिलो हुन्छ।

लुकेका लागत आफैँ राख्नुहोस्। संगठनात्मक प्लेटफर्मको सबैभन्दा ठूलो लागत विरलै लाइसेन्स हुन्छ। नेतृत्वको समय हुन्छ, त्यसपछि संरचना र भूमिकाको हालको डेटा तयार गर्ने काम र मानिसहरूले साँच्चै प्रयोग गर्न चाहिने परिवर्तन। यिनलाई छोड्ने व्यावसायिक प्रस्ताव बढी प्रभावकारी हुँदैनन्। नेतृत्वले जसरी पनि यिनबारे सोच्छ, र छुटाउँदा लेखकको विश्वसनीयता घट्छ।

यो किन काम गर्छ

कारणहरू निर्णय अनुसन्धानमा राम्ररी अभिलेखित छन्। Samuelson र Zeckhauser ले सन् १९८० को दशकको अन्त्यतिर यथास्थिति पूर्वाग्रह वर्णन गरे: मानिसहरूले हालको अवस्था राख्ने र बदल्नेबीच छनोट गर्दा, योग्यताले औचित्य दिनेभन्दा बढी हालको अवस्थालाई रोज्छन्। त्यसैले व्यावसायिक प्रस्तावले यथास्थितिलाई तटस्थ पूर्वनिर्धारितका रूपमा होइन, आफ्नै लागत भएको छनोटका रूपमा देखाउनुपर्छ। केही नगर्दाको लागत खण्डले त्यही गर्छ।

Kahneman र Tversky को prospect theory ले सामग्रीसँगै प्रस्तुतिको ढाँचा पनि किन महत्त्वपूर्ण छ भनी बताउँछ। बराबरको लाभभन्दा हानि ठूलो देखिन्छ, त्यसैले नेतृत्वले पहिल्यै मूल्य तिरिरहेको समस्यालाई पाउन सकिने फाइदाभन्दा बढी भारी तौलिन्छ। John Kotter ले Leading Change मा संगठनात्मक शब्दमा उही कुरा भने: कुनै पनि परिवर्तनको पहिलो कदम तात्कालिकताको भाव स्थापित गर्नु हो, र शून्यबाट तात्कालिकता सिर्जना गर्नुपर्ने व्यावसायिक प्रस्ताव उकालो लडिरहेको हुन्छ।

अन्त्यमा, यो हामीले यस्ता प्लेटफर्मबाट मूल्य पाउने संगठनहरूमा देख्ने कुरासँग मेल खान्छ। मूल्य झन्डै कहिल्यै सफ्टवेयरबाट मात्र आउँदैन; यो फरक निर्णय गर्ने नेतृत्व टोलीबाट आउँछ, किनभने उनीहरूलाई चाहिने संरचना, स्वामित्व र मापनहरू अन्ततः एउटै ठाउँमा देखिन्छन्। रणनीति कार्यान्वयन किन असफल हुन्छ र निर्णय बहाव बारेका हाम्रा लेखहरूले त्यो दृश्यतालाई मूल्य तिर्न लायक बनाउने समस्याहरू वर्णन गर्छन्।

एक व्यावहारिक सूची

• समस्या नेतृत्वकै शब्दमा खोज्नुहोस्: अफसाइटका टिपोट, सञ्चालक समितिका छलफल, प्रमुख कार्यकारीले दोहोर्‍याइरहने गुनासो।
• समस्याको एउटा घटनाको लागत अनुमान गर्नुहोस्, संयमित रूपमा र दायरामा, HR का होइन, व्यावसायिक शब्दमा।
• के फरक तरिकाले र कसले निर्णय गर्नेछ भनी एउटा वाक्य लेख्नुहोस्। सक्नुहुन्न भने, रोकिएर खरिदबारे पुनर्विचार गर्नुहोस्।
• वास्तविक समस्यामा पाइलट डिजाइन गर्नुहोस्, समयसीमाभित्र, निर्णयकर्ताहरू संलग्न भएको र पहिल्यै सहमति गरिएको मापनसहित।
• पूरा लागत सूचीबद्ध गर्नुहोस्, नेतृत्वको समय, डेटा तयारी, कन्फिगरेसन, तालिम र परिवर्तन सहयोगसहित।
• चरणबद्ध प्रतिबद्धता माग्नुहोस् पाइलटको नतिजासँग जोडेर, र तपाईं कसरी रोक्नुहुनेछ भन्ने पनि समावेश गर्नुहोस्।
• प्रस्ताव गर्नुअघि उपयुक्तता इमानदारीपूर्वक जाँच्नुहोस्। Green Apple कसका लागि बनाइएको हो र यो अन्य प्लेटफर्मसँग कसरी तुलना हुन्छ भन्ने हाम्रा गाइडहरू तपाईंलाई हामीलाई छान्न मात्र होइन, हटाउन पनि मद्दत गर्न लेखिएका हुन्।

आफैँलाई सोध्नुहोस्

• हाम्रो नेतृत्वले यो वर्ष एकपटकभन्दा बढी कुन संगठनात्मक समस्याको गुनासो गरिसकेको छ?
• त्यो समस्याको पछिल्लो घटनाले हामीलाई CFO ले चिन्ने शब्दमा मोटामोटी कति खर्च गरायो?
• यो प्लेटफर्म भएको भए कसले कुन निर्णय फरक तरिकाले गर्थे, र के हामीले उनीहरूलाई सोधेका छौँ?
• नब्बे दिनको पाइलटको कस्तो नतिजाले हामीलाई विस्तार गर्न मनाउँछ, र कस्तो नतिजाले रोक्न मनाउँछ?
• के हामी यो समस्या समाधान गर्न किन्दै छौँ, कि हामीजस्ता अरू कम्पनीसँग यो भएकाले?

निचोड

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