OD ও ট্যালেন্ট platform-এর business case: software নয়, সিদ্ধান্তটি বিক্রি করুন
Organization development আর talent software-এর বেশিরভাগ business case প্রথম দশ মিনিটেই ব্যর্থ হয়, কারণ তারা এমন একটি নেতৃত্ব দলের কাছে feature আর সাশ্রয় হওয়া ঘণ্টার বর্ণনা দেয়, যারা দেখে নরম সুফলসহ একটি খরচ। One-Decision Business Case অনুরোধটিকে নোঙর করে এমন একটি ব্যয়বহুল সমস্যায় যা নেতৃত্ব ইতিমধ্যে টের পাচ্ছে, আর বাজেটের আগে একটি pilot চায়।

Organization development আর talent software-এর বেশিরভাগ business case সভার প্রথম দশ মিনিটেই হারিয়ে যায়, আর একই কারণে। তারা software-এর বর্ণনা দেয়: feature, module, integration, প্রতি manager-এর সাশ্রয় হওয়া ঘণ্টা। শীর্ষ নেতৃত্ব শোনে একটি নতুন খরচ, যার সুফল শোনায় নরম আর আসে পরে। যে case-গুলো অনুমোদন পায় সেগুলো গড়া হয় উল্টো দিক থেকে। সেগুলো শুরু হয় এমন একটি ব্যয়বহুল, পুনরাবৃত্ত সাংগঠনিক সমস্যা থেকে যা নেতৃত্ব ইতিমধ্যে টের পাচ্ছে, দেখায় সমস্যাটির খরচ কত, আর platform-কে উপস্থাপন করে সেই খরচ বন্ধ করার সবচেয়ে সস্তা বিশ্বাসযোগ্য উপায় হিসেবে। আর বাজেট চাওয়ার আগে তারা একটি pilot চায়।
আমরা এই আলাপের দুই দিকেই থেকেছি: HR ও strategy নেতাদের case গড়তে সাহায্য করেছি, আবার যে নেতৃত্ব দলগুলো সিদ্ধান্ত নেয় তাদের মুখোমুখিও বসেছি। প্রতিবার আমরা একটি অস্বস্তিকর পরামর্শ দিই: platform-টি কোন সিদ্ধান্ত বদলাবে তার নাম যদি বলতে না পারেন, তাহলে এটি কেনা উচিত নয়। আমাদেরটা কেনার ক্ষেত্রেও একই কথা।
“আপনি বলেছেন এটি কী করে, কিন্তু কী বদলাবে তা বলেননি”
সৌদি আরবের প্রায় তিনশ কর্মীর একটি কোম্পানির HR director কয়েক সপ্তাহ ধরে একটি talent ও organization development platform-এর business case তৈরি করেছিলেন। তা দাঁড়িয়েছিল ত্রিশটি slide-এ: চারটি vendor-এর feature তুলনা, performance review আর রিপোর্টিংয়ে সাশ্রয় হওয়া ঘণ্টার অনুমান, vendor-এর সংখ্যা থেকে গড়া return-on-investment হিসাব।
Chief financial officer প্রায় দশ মিনিটে তা নাকচ করে দিলেন। HR director-এর মনে যা থেকে গেল তা হলো কারণটি: “আপনি আমাকে বলেছেন এটি কী করে। কী বদলাবে, বা কে তা বদলাবে, সেটা বলেননি।”
দ্বিতীয় চেষ্টা ছিল একটিমাত্র slide। কয়েক মাস আগের নেতৃত্ব offsite-এ CEO অভিযোগ করেছিলেন যে বছরের তিনটি কৌশলগত initiative আটকে গেছে, আর কেউ বলতে পারছে না সেগুলোর মালিক কে। নতুন case সেই সমস্যার নাম দিল, তিনটির মধ্যে কেবল একটি initiative থেকে বিলম্বিত আয়ের অনুমান করল, নব্বই দিনের একটি pilot প্রস্তাব করল যেখানে নেতৃত্ব দল platform ব্যবহার করে ওই তিনটি initiative-এর মালিকানা ঠিক করবে ও সেগুলো অনুসরণ করবে, আর অর্থ চাইল কেবল তখনই, যদি pilot আগে থেকে সম্মত একটি measure পূরণ করে। একই সভায় তা অনুমোদন পেল।
One-Decision Business Case
দ্বিতীয় চেষ্টার পেছনের কাঠামোর পাঁচটি অংশ, আর এটি কেবল software নয়, প্রায় যেকোনো সাংগঠনিক বিনিয়োগের জন্য কাজ করে।
- সমস্যা। নাম দেওয়া একটি পুনরাবৃত্ত, ব্যয়বহুল সাংগঠনিক সমস্যা যা নেতৃত্ব ইতিমধ্যে টের পেয়েছে, সম্ভব হলে তাদের নিজেদের ভাষায়। আটকে থাকা initiative, অস্পষ্ট decision rights, একটি গুরুত্বপূর্ণ দলে অনুশোচনার মতো কর্মী-প্রস্থান, এমন একটি পুনর্গঠন যা জায়গামতো বসেনি। নেতৃত্ব যদি ইতিমধ্যে বিশ্বাস না করে যে সমস্যাটি আছে, কোনো business case তাদের রাজি করাবে না; তার বদলে সেখান থেকে শুরু করুন।
- কিছু না করার খরচ। সমস্যাটি চলতে থাকলে তার খরচ কত, তার একটি পরিসরভিত্তিক অনুমান, নেতৃত্ব ইতিমধ্যে যে ভাষা ব্যবহার করে সেই ভাষায়: বিলম্বিত আয়, হারানো চুক্তি, প্রতিস্থাপনের খরচ, escalation-এ ব্যয় হওয়া management-এর সময়। রক্ষণশীল ও বিশ্বাসযোগ্য অনুমান বড় ও বিতর্কিত অনুমানের চেয়ে ভালো।
- পরিবর্তন। কোন সিদ্ধান্ত বা আচরণ ভিন্ন হবে, আর কে তা ভিন্নভাবে করবে। বেশিরভাগ case এই অংশটিই বাদ দেয়, আর গল্পের CFO ঠিক এটিই চাইছিলেন। Software নিজে থেকে কিছুই বদলায় না; মানুষ তা ব্যবহার করে ভিন্নভাবে সিদ্ধান্ত নিলে বদলায়।
- প্রমাণ। বাস্তব সমস্যার ওপর একটি ছোট, নির্দিষ্ট সময়ে বাঁধা pilot, যাদের সিদ্ধান্ত বদলানোর কথা তাদের নিয়ে, আর শুরুর আগেই সম্মত একটি measure-সহ।
- অনুরোধ। Pilot-এর ফলের সঙ্গে বাঁধা একটি ধাপে ধাপে প্রতিশ্রুতি, অভ্যন্তরীণ সময়সহ পূর্ণ খরচ উল্লেখ করে, আর কাজ না করলে থামার একটি স্পষ্ট উপায়সহ।
এভাবে গড়া একটি case প্রায়ই এক পাতার চেয়ে ছোট হয়। এটি দুর্বলতা নয়; এটিই এমন একটি নেতৃত্ব দলের কাছে তা পড়ার যোগ্য করে তোলে, যাদের সেই মাসে আরও চল্লিশটি সিদ্ধান্ত নিতে হবে।
এবার প্রচলিত মতের বিপরীত কথাটি
ROI শতাংশ দিয়ে শুরু করবেন না। Software business case-এর এই অংশটিই নেতৃত্ব সবচেয়ে কম বিশ্বাস করে, কারণ তারা জানে এটি vendor-এর কাছ থেকে এসেছে, আর এটি আলোচনাকে সমস্যা থেকে সরিয়ে সংখ্যার পেছনের অনুমানগুলোর দিকে নিয়ে যায়। নেতৃত্ব ইতিমধ্যে বিশ্বাস করে এমন একটি খরচের পরিমিত অনুমান এমন বড় একটি return-এর চেয়ে অনেক বেশি প্ররোচক, যা তাদের বিশ্বাসের ওপর ভর করে মেনে নিতে হয়।
যা দরকার তার চেয়ে কম চান। Pilot-সহ একটি ধাপে ধাপে প্রতিশ্রুতি একটি বড় বার্ষিক চুক্তির চেয়ে অনুমোদন করা সহজ, আর এটি নেতৃত্ব যে প্রশ্নের উত্তর দিচ্ছে তা বদলে দেয় “এটি কি টাকার যোগ্য?” থেকে “এটি কি নব্বই দিনের যোগ্য?”-তে। Pilot কাজ করলে দ্বিতীয় অনুমোদন প্রথমটির চেয়ে অনেক সহজ হয়।
লুকানো খরচগুলো নিজেই যোগ করুন। একটি সাংগঠনিক platform-এর সবচেয়ে বড় খরচ খুব কমই লাইসেন্স। সবচেয়ে বড় খরচ নেতৃত্বের সময়, তার পরে কাঠামো ও ভূমিকার বর্তমান data প্রস্তুতের কাজ আর মানুষকে সত্যিই এটি ব্যবহার করাতে প্রয়োজনীয় পরিবর্তন। যে business case এগুলো বাদ দেয় তা বেশি প্ররোচক হয় না। নেতৃত্ব যেভাবেই হোক এগুলোর কথা ভাবে, আর এই বাদ দেওয়া লেখকের বিশ্বাসযোগ্যতা কেড়ে নেয়।
এটি কেন কাজ করে
কারণগুলো decision গবেষণায় ভালোভাবে নথিভুক্ত। Samuelson ও Zeckhauser ১৯৮০-এর দশকের শেষে status quo bias বর্ণনা করেছিলেন: বর্তমান অবস্থা ধরে রাখা আর বদলানোর মধ্যে বাছাই করার সময় মানুষ যোগ্যতার চেয়ে বেশি বর্তমান অবস্থার দিকে ঝোঁকে। তাই একটি business case-কে status quo-কে দৃশ্যমান করতে হবে নিজস্ব খরচসহ একটি পছন্দ হিসেবে, নিরপেক্ষ default হিসেবে নয়। কিছু না করার খরচের অংশটি ঠিক এটিই করে।
Kahneman ও Tversky-র prospect theory ব্যাখ্যা করে কেন বিষয়বস্তুর পাশাপাশি উপস্থাপনার ধরনও গুরুত্বপূর্ণ। সমপরিমাণ লাভের চেয়ে ক্ষতি বড় দেখায়, তাই নেতৃত্ব ইতিমধ্যে যে সমস্যার খরচ দিচ্ছে তার ওজন একটি সম্ভাব্য সুফলের চেয়ে বেশি। John Kotter Leading Change-এ সাংগঠনিক ভাষায় একই কথা বলেছিলেন: যেকোনো পরিবর্তনের প্রথম ধাপ হলো জরুরি তাগিদ তৈরি করা, আর যে business case-কে শূন্য থেকে তাগিদ তৈরি করতে হয় সে উজানে লড়ছে।
শেষত, এটি মেলে আমরা যা দেখি তার সঙ্গে, সেই প্রতিষ্ঠানগুলোতে যারা এ ধরনের platform থেকে মূল্য পায়। মূল্য প্রায় কখনোই কেবল software থেকে আসে না; তা আসে একটি নেতৃত্ব দলের ভিন্নভাবে সিদ্ধান্ত নেওয়া থেকে, কারণ তাদের প্রয়োজনীয় কাঠামো, মালিকানা আর measures অবশেষে এক জায়গায় দৃশ্যমান। Strategy execution কেন ব্যর্থ হয় আর decision drift নিয়ে আমাদের লেখাগুলো সেই সমস্যাগুলো বর্ণনা করে, যা এই দৃশ্যমানতাকে টাকা দেওয়ার যোগ্য করে তোলে।
একটি ব্যবহারিক checklist
- সমস্যাটি খুঁজুন নেতৃত্বের নিজের ভাষায়: offsite-এর নোট, board-এর আলোচনা, CEO বারবার যে অভিযোগ করেন।
- সমস্যাটির একটি ঘটনার খরচ অনুমান করুন, রক্ষণশীলভাবে ও পরিসর ধরে, HR-এর ভাষায় নয়, ব্যবসার ভাষায়।
- কী ভিন্নভাবে সিদ্ধান্ত হবে আর কে নেবে, তা এক বাক্যে লিখুন। না পারলে থামুন আর কেনাটা নিয়ে আবার ভাবুন।
- বাস্তব সমস্যার ওপর একটি pilot ডিজাইন করুন, নির্দিষ্ট সময়ে বাঁধা, সিদ্ধান্তগ্রহীতাদের যুক্ত করে আর আগে থেকে সম্মত একটি measure-সহ।
- পূর্ণ খরচের তালিকা করুন, নেতৃত্বের সময়, data প্রস্তুতি, configuration, প্রশিক্ষণ আর পরিবর্তন-সহায়তাসহ।
- Pilot-এর ফলের সঙ্গে বাঁধা একটি ধাপে ধাপে প্রতিশ্রুতি চান, আর কীভাবে থামবেন তাও রাখুন।
- Pitch করার আগে সৎভাবে মিল যাচাই করুন। Green Apple কাদের জন্য তৈরি আর অন্যান্য platform-এর সঙ্গে এর তুলনা নিয়ে আমাদের গাইডগুলো লেখা হয়েছে আপনাকে আমাদের বাদ দিতেও সাহায্য করতে, বেছে নিতেও।
নিজেকে জিজ্ঞেস করুন
- কোন সাংগঠনিক সমস্যা নিয়ে আমাদের নেতৃত্ব এই বছর একাধিকবার অভিযোগ করেছে?
- সেই সমস্যার শেষ ঘটনাটির খরচ মোটামুটি কত ছিল, CFO চিনবেন এমন ভাষায়?
- এই platform থাকলে কে কোন সিদ্ধান্ত ভিন্নভাবে নিতেন, আর আমরা কি তাঁদের জিজ্ঞেস করেছি?
- নব্বই দিনের pilot-এর কোন ফল আমাদের বাড়াতে রাজি করাবে, আর কোন ফল থামাতে?
- আমরা কি এটি কিনছি একটি সমস্যা সমাধানে, নাকি কারণ আমাদের মতো অন্য কোম্পানিগুলোর এটি আছে?
সারকথা
শীর্ষ নেতৃত্ব software-এ অর্থ দেয় না। তারা অর্থ দেয় এমন একটি সমস্যার সমাপ্তিতে, যার খরচ তারা ইতিমধ্যে দিচ্ছে। সেই সমস্যার নাম দিন নেতৃত্বের নিজের ভাষায়, সৎভাবে তার খরচ অনুমান করুন, বলুন কে ভিন্নভাবে সিদ্ধান্ত নেবে, একটি সম্মত ফলের বিপরীতে মাপা ছোট pilot দিয়ে তা প্রমাণ করুন, আর একটি ধাপে ধাপে প্রতিশ্রুতি চান। Platform-টি কোন সিদ্ধান্ত বদলাবে তার নাম যদি বলতে না পারেন, তাহলে সবচেয়ে বিশ্বাসযোগ্য business case হলো সেটি, যা আপনি জমা দেন না।
সচরাচর জিজ্ঞাস্য
- একটি talent management বা OD platform-এর business case কীভাবে লিখব?
- এটিকে নোঙর করুন একটি পুনরাবৃত্ত, ব্যয়বহুল সাংগঠনিক সমস্যায় যা নেতৃত্ব ইতিমধ্যে চেনে, যেমন আটকে থাকা কৌশলগত initiative বা একটি গুরুত্বপূর্ণ দলে কর্মী চলে যাওয়া। কিছু না বদলালে সমস্যাটির খরচ কত তা অনুমান করুন, কোন সিদ্ধান্ত বা আচরণ বদলাবে আর কে তা বদলাবে তা বর্ণনা করুন, আগে থেকে সম্মত একটি measure-সহ একটি ছোট pilot প্রস্তাব করুন, আর pilot-এর ফলের সঙ্গে বাঁধা একটি ধাপে ধাপে বাজেট চান।
- Organization development-এর ROI কীভাবে হিসাব করবেন?
- সৎভাবে, আর পরিসর ধরে। বিনিয়োগটি যে নির্দিষ্ট সমস্যাকে লক্ষ্য করে তার খরচ অনুমান করুন, নেতৃত্ব ইতিমধ্যে যে ভাষা ব্যবহার করে সেই ভাষায়: বিলম্বিত আয়, হারানো চুক্তি, প্রতিস্থাপনের খরচ, management-এর সময়। সাধারণ productivity গুণক এড়িয়ে চলুন, যা বেশিরভাগ business case-এর সবচেয়ে কম বিশ্বাসযোগ্য অংশ। নেতৃত্ব ইতিমধ্যে বিশ্বাস করে এমন একটি খরচের রক্ষণশীল অনুমান এমন বড় একটি সংখ্যার চেয়ে বেশি মূল্যবান যা তারা বিশ্বাস করে না।
- Software-এর business case-এ CFO-রা কী দেখতে চান?
- নাম দেওয়া একটি সমস্যা, তার খরচের একটি বিশ্বাসযোগ্য অনুমান, কী বদলাবে আর তার জন্য কে জবাবদিহি করবে তার স্পষ্ট বিবরণ, অভ্যন্তরীণ সময়সহ পূর্ণ খরচ, আর কাজ না করলে থামার একটি উপায়। একটি pilot আর সম্মত measure-সহ ধাপে ধাপে প্রতিশ্রুতি একজন CFO-র বেশিরভাগ আপত্তির উত্তর দিয়ে দেয়, সেগুলো ওঠার আগেই।
- একটি talent বা OD platform কেনার আগে কি pilot চালানো উচিত?
- হ্যাঁ, আর কোনো demo পরিস্থিতিতে নয়, একটি বাস্তব সমস্যায়। Pilot-কে নির্দিষ্ট সময়ে বাঁধুন, যাদের সিদ্ধান্ত platform-টির বদলানোর কথা তাদের যুক্ত করুন, আর শুরুর আগেই একমত হোন কোন ফল এটিকে বাড়ানোর যৌক্তিকতা দেবে। সম্মত measure ছাড়া একটি pilot তৈরি করে মতামত, প্রমাণ নয়।
- লাইসেন্স ছাড়া business case-এ আর কোন খরচ রাখা উচিত?
- নেতৃত্ব ও management-এর সময়, যা সাধারণত সবচেয়ে বড় খরচ; বর্তমান কাঠামো ও ভূমিকার মতো data প্রস্তুতের পরিশ্রম; configuration ও প্রশিক্ষণ; আর মানুষ যাতে এটি ব্যবহার করে তার জন্য প্রয়োজনীয় পরিবর্তনের কাজ। এগুলো রাখলে case আরও বিশ্বাসযোগ্য হয়, কারণ নেতৃত্ব যেভাবেই হোক এগুলোর কথা ভাববে।
সম্পর্কিত নিবন্ধ
Organization Developmentবোর্ডের জন্য সংস্কৃতির metrics: আবহাওয়ার খবর দেওয়া বন্ধ করুন8 মিনিট পড়া
Organization DevelopmentChange Management: বেশিরভাগ পরিবর্তন কেন মাঝপথে ব্যর্থ হয়6 মিনিট পড়া
Organization Developmentআপনার Daily Huddle কি Alignment-এর জন্য — নাকি Control-এর জন্য?8 মিনিট পড়া
Organization Developmentযখন Agile আর কাজ করে না7 মিনিট পড়া