OD और Talent Platform का Business Case: software नहीं, फ़ैसला बेचिए

संगठन विकास और talent software के ज़्यादातर business cases meeting के पहले दस मिनट में हार जाते हैं, और एक ही कारण से। वे software का वर्णन करते हैं: features, modules, integrations, हर manager के बचाए गए घंटे। वरिष्ठ leadership को एक नई लागत सुनाई देती है जिसके लाभ नरम लगते हैं और देर से आते हैं। जो cases मंज़ूर होते हैं वे उलटे ढंग से बनाए जाते हैं। वे एक महँगी, बार-बार होने वाली संगठनात्मक समस्या से शुरू होते हैं जिसे leadership पहले से महसूस करती है, दिखाते हैं कि उस समस्या की लागत क्या है, और platform को उसका भुगतान बंद करने के सबसे सस्ते विश्वसनीय तरीक़े के रूप में पेश करते हैं। और वे budget माँगने से पहले pilot माँगते हैं।

हम इस बातचीत के दोनों तरफ़ रहे हैं, HR और strategy leaders को cases बनाने में मदद करते हुए और उन leadership teams के सामने बैठते हुए जो उन पर फ़ैसला करती हैं। एक असहज सलाह हम हर बार देते हैं: अगर आप उस फ़ैसले का नाम नहीं ले सकते जिसे platform बदलेगा, तो आपको उसे नहीं ख़रीदना चाहिए। इसमें हमारा platform ख़रीदना भी शामिल है।

“आपने बताया कि यह क्या करता है, यह नहीं कि क्या बदलता है”

सऊदी अरब की लगभग तीन सौ कर्मचारियों वाली एक कंपनी की HR director ने एक talent और संगठन विकास platform के लिए business case तैयार करने में कई हफ़्ते लगाए। वह तीस slides का था: चार vendors की feature तुलना, performance reviews और reporting पर बचाए गए अनुमानित घंटे, vendor के आँकड़ों से बना return-on-investment हिसाब।

Chief financial officer ने लगभग दस मिनट में उसे अस्वीकार कर दिया। HR director के मन में जो बात रह गई वह कारण था: “आपने मुझे बताया कि यह क्या करता है। आपने यह नहीं बताया कि क्या बदलता है, या उसे कौन बदलता है।”

दूसरी कोशिश एक slide की थी। कुछ महीने पहले leadership offsite में CEO ने शिकायत की थी कि साल की तीन रणनीतिक initiatives अटक गई हैं, और कोई नहीं बता सकता कि उनका मालिक कौन है। नए case ने उस समस्या का नाम लिया, तीन में से सिर्फ़ एक initiative से देरी से आई आय का अनुमान लगाया, एक नब्बे-दिन का pilot प्रस्तावित किया जिसमें leadership team platform का इस्तेमाल करके उन तीन initiatives का स्वामित्व तय करती और उन्हें track करती, और funding केवल तभी माँगी अगर pilot पहले से तय measure पर खरा उतरे। वह उसी meeting में मंज़ूर हो गया।

One-Decision Business Case

दूसरी कोशिश के पीछे की संरचना के पाँच हिस्से हैं, और यह लगभग किसी भी संगठनात्मक निवेश के लिए काम करती है, केवल software के लिए नहीं।

1. समस्या। एक नामित, बार-बार होने वाली, महँगी संगठनात्मक समस्या जिसे leadership पहले से महसूस कर चुकी है, आदर्श रूप से उनके अपने शब्दों में। अटकी initiatives, अस्पष्ट decision rights, किसी अहम team में पछतावे वाला attrition, एक restructuring जो ज़मीन पर नहीं उतरी। अगर leadership पहले से नहीं मानती कि समस्या मौजूद है, तो कोई business case उन्हें मना नहीं पाएगा; इसके बजाय वहीं से शुरू कीजिए।
2. कुछ न करने की लागत। दायरों में एक अनुमान कि समस्या जारी रहने पर उसकी लागत क्या है, उन शब्दों में जो leadership पहले से इस्तेमाल करती है: देरी से आई आय, खोए contracts, बदलने की लागत, escalations पर लगा management का समय। रूढ़िवादी और विश्वसनीय, बड़े और विवादित से बेहतर है।
3. बदलाव। कौन सा फ़ैसला या व्यवहार अलग होगा, और उसे अलग ढंग से कौन करेगा। यह वह हिस्सा है जिसे ज़्यादातर cases छोड़ देते हैं, और यही वह हिस्सा है जो कहानी का CFO माँग रहा था। Software अपने आप कुछ नहीं बदलता; लोग उसका इस्तेमाल करके अलग फ़ैसले लेते हैं, तब बदलता है।
4. प्रमाण। असली समस्या पर एक छोटा, समय-सीमा वाला pilot, उन लोगों के साथ जिनके फ़ैसले बदलने हैं, और शुरू होने से पहले तय एक measure।
5. माँग। Pilot के नतीजे से बँधी एक चरणबद्ध प्रतिबद्धता, भीतरी समय सहित पूरी लागत बताते हुए, और काम न करने पर रुकने का स्पष्ट तरीक़ा।

इस तरह बना case अक्सर एक पन्ने से छोटा होता है। यह कमज़ोरी नहीं है; यही उसे ऐसी leadership team के लिए पढ़ने योग्य बनाता है जिसके सामने उस महीने चालीस और फ़ैसले हैं।

और यह रही उलटी बात

ROI प्रतिशत से शुरुआत मत कीजिए। यह software business case का वह हिस्सा है जिस पर leadership सबसे कम भरोसा करती है, क्योंकि उन्हें पता है कि यह vendor से आया है, और यह चर्चा को समस्या से हटाकर संख्या के पीछे की मान्यताओं पर ले जाता है। जिस लागत पर leadership पहले से यक़ीन करती है उसका मामूली अनुमान उस बड़े return से कहीं ज़्यादा प्रभावी है जिसे उन्हें आँख मूँदकर मानना पड़े।

जितना चाहिए उससे कम माँगिए। Pilot के साथ चरणबद्ध प्रतिबद्धता किसी बड़े वार्षिक contract से मंज़ूर कराना आसान है, और यह leadership के सामने का सवाल “क्या यह पैसे के लायक़ है?” से बदलकर “क्या यह नब्बे दिनों के लायक़ है?” कर देती है। अगर pilot काम करता है, तो दूसरी मंज़ूरी उससे कहीं आसान होती है जितनी पहली होती।

छिपी लागतें ख़ुद डालिए। किसी संगठनात्मक platform की सबसे बड़ी लागत शायद ही कभी licence होती है। वह leadership का समय है, उसके बाद संरचना और भूमिकाओं का मौजूदा data तैयार करने का काम और लोगों के सचमुच इसे इस्तेमाल करने के लिए ज़रूरी बदलाव। जो business cases इन्हें छोड़ देते हैं वे ज़्यादा प्रभावी नहीं होते। Leadership वैसे भी इनके बारे में सोचती है, और यह चूक लेखक की विश्वसनीयता की क़ीमत पर होती है।

यह क्यों काम करता है

इसके कारण decision research में अच्छी तरह दर्ज हैं। Samuelson और Zeckhauser ने 1980 के दशक के अंत में status quo bias का वर्णन किया: जब लोग मौजूदा स्थिति रखने और उसे बदलने के बीच चुनते हैं, तो वे मौजूदा स्थिति को उसकी योग्यता से ज़्यादा तरजीह देते हैं। इसलिए business case को status quo को एक तटस्थ default के बजाय अपनी लागतों वाले चुनाव के रूप में दिखाना होता है। कुछ न करने की लागत वाला हिस्सा यही करता है।

Kahneman और Tversky की prospect theory बताती है कि सामग्री के साथ-साथ framing क्यों मायने रखती है। नुक़सान बराबर के लाभों से बड़े दिखते हैं, इसलिए जिस समस्या का leadership पहले से भुगतान कर रही है उसे उस लाभ से ज़्यादा वज़न मिलता है जो उन्हें मिल सकता है। John Kotter ने Leading Change में यही बात संगठनात्मक शब्दों में कही: किसी भी बदलाव का पहला क़दम तात्कालिकता की भावना स्थापित करना है, और जिस business case को शून्य से तात्कालिकता पैदा करनी पड़े वह चढ़ाई पर लड़ रहा है।

अंत में, यह उससे मेल खाता है जो हम उन संगठनों में देखते हैं जिन्हें ऐसे platforms से मूल्य मिलता है। मूल्य लगभग कभी अकेले software से नहीं आता; वह एक leadership team के अलग फ़ैसले लेने से आता है, क्योंकि उन्हें जिस संरचना, स्वामित्व और measures की ज़रूरत है वे आख़िरकार एक जगह दिखाई देते हैं। Strategy execution क्यों विफल होती है और decision drift पर हमारे लेख उन समस्याओं का वर्णन करते हैं जो इस दृश्यता को भुगतान के लायक़ बनाती हैं।

एक व्यावहारिक checklist

• समस्या leadership के अपने शब्दों में ढूँढ़िए: offsite notes, board की चर्चाएँ, वह शिकायत जो CEO बार-बार दोहराते हैं।
• समस्या के एक उदाहरण की लागत का अनुमान लगाइए, रूढ़िवादी ढंग से और दायरों में, HR के बजाय business की भाषा में।
• एक वाक्य लिखिए कि क्या अलग ढंग से तय होगा और किसके द्वारा। अगर नहीं लिख सकते, तो रुकिए और ख़रीद पर फिर से सोचिए।
• असली समस्या पर एक pilot design कीजिए, समय-सीमा में, फ़ैसला लेने वालों को शामिल करके और पहले से तय measure के साथ।
• पूरी लागत सूचीबद्ध कीजिए, जिसमें leadership का समय, data तैयारी, configuration, training और बदलाव का सहारा शामिल हो।
• चरणबद्ध प्रतिबद्धता माँगिए जो pilot के नतीजे से बँधी हो, और यह शामिल कीजिए कि आप कैसे रुकेंगे।
• Pitch से पहले ईमानदारी से fit जाँचिए। Green Apple किसके लिए बना है और यह दूसरे platforms से कैसे तुलना करता है पर हमारी guides इसलिए लिखी गई हैं कि आप हमें चुन सकें और ख़ारिज भी कर सकें।

ख़ुद से पूछिए

• कौन सी संगठनात्मक समस्या की हमारी leadership इस साल एक से ज़्यादा बार शिकायत कर चुकी है?
• उस समस्या के पिछले उदाहरण की हमें मोटे तौर पर क्या क़ीमत चुकानी पड़ी, ऐसे शब्दों में जिन्हें CFO पहचान सके?
• यह platform होने पर कौन सा फ़ैसला कौन अलग ढंग से लेगा, और क्या हमने उनसे पूछा है?
• नब्बे-दिन के pilot का कौन सा नतीजा हमें विस्तार के लिए मना लेगा, और कौन सा रुकने के लिए?
• क्या हम इसे किसी समस्या को हल करने के लिए ख़रीद रहे हैं, या इसलिए कि हमारे जैसी दूसरी कंपनियों के पास यह है?

निष्कर्ष

वरिष्ठ leadership software को funding नहीं देती। वह उस समस्या के अंत को funding देती है जिसका वह पहले से भुगतान कर रही है। उस समस्या का नाम leadership के अपने शब्दों में लीजिए, उसकी लागत का ईमानदारी से अनुमान लगाइए, बताइए कि कौन अलग फ़ैसला लेगा, तय नतीजे के मुक़ाबले मापे गए एक छोटे pilot से इसे साबित कीजिए, और चरणबद्ध प्रतिबद्धता माँगिए। अगर आप उस फ़ैसले का नाम नहीं ले सकते जिसे platform बदलेगा, तो सबसे विश्वसनीय business case वह है जिसे आप जमा ही न करें।