تنظیمی ترقی اور ٹیلنٹ پلیٹ فارم کا بزنس کیس: سافٹ ویئر نہیں، فیصلہ بیچیے

تنظیمی ترقی اور ٹیلنٹ سافٹ ویئر کے زیادہ تر بزنس کیس اجلاس کے پہلے دس منٹ میں ہار جاتے ہیں، اور ایک ہی وجہ سے۔ وہ سافٹ ویئر بیان کرتے ہیں: فیچرز، ماڈیولز، انضمام، فی منیجر بچائے گئے گھنٹے۔ سینئر قیادت کو ایک نئی لاگت سنائی دیتی ہے جس کے فوائد نرم لگتے ہیں اور بعد میں آتے ہیں۔ جو کیس منظور ہوتے ہیں وہ الٹی سمت سے بنائے جاتے ہیں۔ وہ ایک مہنگے، بار بار آنے والے تنظیمی مسئلے سے شروع ہوتے ہیں جسے قیادت پہلے سے محسوس کرتی ہے، دکھاتے ہیں کہ وہ مسئلہ کتنے کا پڑتا ہے، اور پلیٹ فارم کو اُس کی قیمت ادا کرنا بند کرنے کے سب سے سستے قابلِ اعتبار طریقے کے طور پر پیش کرتے ہیں۔ اور وہ بجٹ مانگنے سے پہلے پائلٹ مانگتے ہیں۔

ہم اِس گفتگو کے دونوں طرف رہ چکے ہیں، ایچ آر اور حکمتِ عملی کے رہنماؤں کو کیس بنانے میں مدد دیتے ہوئے اور اُن قیادتی ٹیموں کے سامنے بیٹھتے ہوئے جو اِن پر فیصلہ کرتی ہیں۔ ایک ناگوار مشورہ ہم ہر بار دیتے ہیں: اگر آپ اُس فیصلے کا نام نہیں لے سکتے جسے پلیٹ فارم بدلے گا، تو آپ کو اُسے نہیں خریدنا چاہیے۔ اِس میں ہمارا پلیٹ فارم خریدنا بھی شامل ہے۔

«آپ نے مجھے بتایا کہ یہ کیا کرتا ہے، یہ نہیں کہ کیا بدلے گا»

سعودی عرب میں تقریباً تین سو ملازمین والی ایک کمپنی کے ایچ آر ڈائریکٹر نے ٹیلنٹ اور تنظیمی ترقی کے ایک پلیٹ فارم کے لیے بزنس کیس تیار کرنے میں کئی ہفتے لگائے۔ یہ تیس سلائیڈوں پر مشتمل تھا: چار وینڈرز کے فیچرز کا موازنہ، کارکردگی کے جائزوں اور رپورٹنگ پر بچائے گئے گھنٹوں کا تخمینہ، اور وینڈر کے اعداد سے بنایا گیا سرمایہ کاری پر منافع کا حساب۔

چیف فنانشل آفیسر نے اِسے تقریباً دس منٹ میں مسترد کر دیا۔ ایچ آر ڈائریکٹر کے ذہن میں جو بات رہ گئی وہ وجہ تھی: «آپ نے مجھے بتایا ہے کہ یہ کیا کرتا ہے۔ آپ نے یہ نہیں بتایا کہ کیا بدلے گا، یا اُسے کون بدلے گا۔»

دوسری کوشش ایک سلائیڈ کی تھی۔ چند ماہ پہلے قیادت کی آف سائٹ میں چیف ایگزیکٹو نے شکایت کی تھی کہ سال کے تین اسٹریٹجک اقدامات رکے ہوئے ہیں، اور کوئی نہیں بتا سکتا کہ اُن کا مالک کون ہے۔ نئے کیس نے اُس مسئلے کا نام لیا، تینوں میں سے صرف ایک اقدام کی مؤخر آمدنی کا تخمینہ لگایا، نوے دن کا ایک پائلٹ تجویز کیا جس میں قیادتی ٹیم پلیٹ فارم کو اُن تین اقدامات کی ملکیت طے کرنے اور اُن کی پیروی کے لیے استعمال کرے گی، اور فنڈنگ صرف اِس شرط پر مانگی کہ پائلٹ پیشگی طے شدہ پیمانے پر پورا اترے۔ یہ اُسی اجلاس میں منظور ہو گیا۔

ایک فیصلے والا بزنس کیس

دوسری کوشش کے پیچھے کی ساخت کے پانچ حصے ہیں، اور یہ صرف سافٹ ویئر نہیں بلکہ تقریباً کسی بھی تنظیمی سرمایہ کاری کے لیے کام کرتی ہے۔

1. مسئلہ۔ ایک نامزد، بار بار آنے والا، مہنگا تنظیمی مسئلہ جسے قیادت پہلے محسوس کر چکی ہو، ترجیحاً اُن کے اپنے الفاظ میں۔ رکے ہوئے اقدامات، غیر واضح فیصلہ سازی کے اختیارات، کسی اہم ٹیم سے ایسے لوگوں کا جانا جن کے جانے کا افسوس ہو، ایسی تنظیمِ نو جو جم نہ سکی۔ اگر قیادت پہلے سے یہ نہیں مانتی کہ مسئلہ موجود ہے تو کوئی بزنس کیس اُنہیں قائل نہیں کرے گا؛ اِس کے بجائے آغاز وہیں سے کیجیے۔
2. کچھ نہ کرنے کی لاگت۔ کم اور زیادہ کی حدود میں ایک تخمینہ کہ مسئلہ جاری رہے تو کتنے کا پڑے گا، اُن اصطلاحات میں جو قیادت پہلے سے استعمال کرتی ہے: مؤخر آمدنی، کھوئے ہوئے معاہدے، متبادل کی لاگت، معاملات اوپر بھیجنے پر صرف ہونے والا انتظامیہ کا وقت۔ محتاط اور قابلِ اعتبار، بڑے اور متنازع سے بہتر ہے۔
3. تبدیلی۔ کون سا فیصلہ یا رویّہ مختلف ہوگا، اور اُسے مختلف طریقے سے کون کرے گا۔ یہی وہ حصہ ہے جسے زیادہ تر کیس چھوڑ دیتے ہیں، اور یہی وہ حصہ ہے جو کہانی میں چیف فنانشل آفیسر مانگ رہے تھے۔ سافٹ ویئر خود سے کچھ نہیں بدلتا؛ تبدیلی تب آتی ہے جب لوگ اُسے استعمال کر کے مختلف فیصلے کرتے ہیں۔
4. ثبوت۔ حقیقی مسئلے پر ایک مختصر، وقت کی حد میں بندھا پائلٹ، اُن لوگوں کے ساتھ جن کے فیصلے بدلنے ہیں، اور شروع ہونے سے پہلے طے شدہ ایک پیمانہ۔
5. درخواست۔ پائلٹ کے نتیجے سے بندھا ایک مرحلہ وار وعدہ، پوری لاگت کے بیان کے ساتھ، بشمول اندرونی وقت، اور کام نہ کرنے کی صورت میں رکنے کا ایک واضح طریقہ۔

اِس طرح بنایا گیا کیس اکثر ایک صفحے سے بھی چھوٹا ہوتا ہے۔ یہ کمزوری نہیں؛ یہی اِسے ایک ایسی قیادتی ٹیم کے لیے قابلِ مطالعہ بناتا ہے جسے اُس مہینے چالیس اور فیصلے کرنے ہیں۔

اور یہ رہا غیر روایتی حصہ

آغاز سرمایہ کاری پر منافع کے فیصد سے نہ کیجیے۔ یہ سافٹ ویئر کے بزنس کیس کا وہ حصہ ہے جس پر قیادت سب سے کم بھروسا کرتی ہے، کیونکہ وہ جانتی ہے کہ یہ وینڈر سے آیا ہے، اور یہ بحث کو مسئلے سے ہٹا کر عدد کے پیچھے کے مفروضوں پر لے جاتا ہے۔ ایسی لاگت کا معمولی تخمینہ جس پر قیادت پہلے سے یقین رکھتی ہو، ایک ایسے بڑے منافع سے کہیں زیادہ قائل کرنے والا ہے جسے اُنہیں آنکھ بند کر کے ماننا پڑے۔

جتنی ضرورت ہے اُس سے کم مانگیے۔ پائلٹ کے ساتھ مرحلہ وار وعدہ ایک بڑے سالانہ معاہدے سے زیادہ آسانی سے منظور ہوتا ہے، اور یہ اُس سوال کو بدل دیتا ہے جس کا قیادت جواب دے رہی ہے، «کیا یہ اِس رقم کے قابل ہے؟» سے «کیا یہ نوے دن کے قابل ہے؟» تک۔ اگر پائلٹ کامیاب ہو تو دوسری منظوری اُس سے کہیں آسان ہوتی ہے جتنی پہلی ہوتی۔

پوشیدہ لاگتیں خود شامل کیجیے۔ لائسنس شاذ ہی کسی تنظیمی پلیٹ فارم کی سب سے بڑی لاگت ہوتا ہے۔ سب سے بڑی لاگت قیادت کا وقت ہے، اُس کے بعد ساخت اور کرداروں پر موجودہ ڈیٹا تیار کرنے کا کام اور وہ تبدیلی جو لوگوں کے اِسے واقعی استعمال کرنے کے لیے درکار ہے۔ جو بزنس کیس اِنہیں چھوڑ دیتے ہیں وہ زیادہ قائل کرنے والے نہیں ہوتے۔ قیادت بہرحال اِن کے بارے میں سوچتی ہے، اور یہ کمی لکھنے والے کی ساکھ کو نقصان پہنچاتی ہے۔

یہ کیوں کام کرتا ہے

اِس کی وجوہات فیصلہ سازی کی تحقیق میں اچھی طرح دستاویزی ہیں۔ Samuelson اور Zeckhauser نے 1980 کی دہائی کے آخر میں «موجودہ حالت کے تعصب» کو بیان کیا: جب لوگ موجودہ حالت برقرار رکھنے اور اُسے بدلنے کے درمیان انتخاب کرتے ہیں تو وہ موجودہ حالت کو اُس سے زیادہ ترجیح دیتے ہیں جتنا اُس کی خوبیاں جواز دیتی ہیں۔ اِس لیے بزنس کیس کو موجودہ حالت کو ایک ایسے انتخاب کے طور پر دکھانا ہوتا ہے جس کی اپنی لاگتیں ہیں، نہ کہ ایک غیر جانبدار طے شدہ صورت کے طور پر۔ کچھ نہ کرنے کی لاگت والا حصہ یہی کرتا ہے۔

Kahneman اور Tversky کی «پراسپیکٹ تھیوری» بتاتی ہے کہ مواد کے ساتھ ساتھ پیشکش کا زاویہ بھی کیوں اہم ہے۔ نقصانات برابر کے فوائد سے بڑے دکھائی دیتے ہیں، اِس لیے ایسا مسئلہ جس کی قیمت قیادت پہلے سے ادا کر رہی ہے، ایسے فائدے سے زیادہ وزن رکھتا ہے جو شاید اُنہیں ملے۔ John Kotter نے Leading Change میں یہی نکتہ تنظیمی زبان میں کہا: کسی بھی تبدیلی کا پہلا قدم فوری ضرورت کا احساس پیدا کرنا ہے، اور جس بزنس کیس کو یہ احساس صفر سے پیدا کرنا ہو وہ چڑھائی پر لڑ رہا ہوتا ہے۔

آخر میں، یہ اُس سے مطابقت رکھتا ہے جو ہم اُن اداروں میں دیکھتے ہیں جو ایسے پلیٹ فارمز سے قدر حاصل کرتے ہیں۔ قدر تقریباً کبھی اکیلے سافٹ ویئر سے نہیں آتی؛ یہ ایک قیادتی ٹیم کے مختلف فیصلے کرنے سے آتی ہے، کیونکہ اُنہیں درکار ساخت، ملکیت اور پیمانے آخرکار ایک جگہ نظر آنے لگتے ہیں۔ ہمارے مضامین حکمتِ عملی کا نفاذ کیوں ناکام ہوتا ہے اور فیصلوں کا بہاؤ اُن مسائل کو بیان کرتے ہیں جن کی وجہ سے یہ نمایاں پن قیمت ادا کرنے کے قابل ہے۔

ایک عملی فہرست

• مسئلہ قیادت کے اپنے الفاظ میں تلاش کیجیے: آف سائٹ کے نوٹس، بورڈ کی بحثیں، وہ شکایت جو چیف ایگزیکٹو بار بار دہراتا ہے۔
• مسئلے کے ایک واقعے کی لاگت کا تخمینہ لگائیے، محتاط انداز میں اور حدود کی صورت میں، ایچ آر کے بجائے کاروباری اصطلاحات میں۔
• ایک جملہ لکھیے کہ کیا مختلف طریقے سے طے ہوگا اور کون طے کرے گا۔ اگر نہیں لکھ سکتے تو رکیے اور خریداری پر دوبارہ غور کیجیے۔
• حقیقی مسئلے پر ایک پائلٹ ڈیزائن کیجیے، وقت کی حد میں، فیصلہ سازوں کی شرکت اور پیشگی طے شدہ پیمانے کے ساتھ۔
• پوری لاگت کی فہرست بنائیے، بشمول قیادت کا وقت، ڈیٹا کی تیاری، ترتیب، تربیت اور تبدیلی میں معاونت۔
• پائلٹ کے نتیجے سے بندھا مرحلہ وار وعدہ مانگیے، اور یہ بھی شامل کیجیے کہ آپ کیسے رکیں گے۔
• پیشکش سے پہلے دیانت داری سے مطابقت جانچیے۔ ہماری رہنمائیاں گرین ایپل کس کے لیے بنایا گیا ہے اور یہ دوسرے پلیٹ فارمز سے کیسے مختلف ہے اِس لیے لکھی گئی ہیں کہ آپ ہمیں شامل کرنے کے ساتھ ساتھ خارج بھی کر سکیں۔

خود سے پوچھیے

• ہماری قیادت اِس سال کس تنظیمی مسئلے کی ایک سے زیادہ بار شکایت کر چکی ہے؟
• اُس مسئلے کے پچھلے واقعے کی ہمیں موٹے طور پر کتنی قیمت پڑی، ایسی اصطلاحات میں جنہیں چیف فنانشل آفیسر پہچانے؟
• اگر یہ پلیٹ فارم موجود ہوتا تو کون کون سا فیصلہ مختلف طریقے سے کرتا، اور کیا ہم نے اُن سے پوچھا ہے؟
• نوے دن کے پائلٹ کا کون سا نتیجہ ہمیں وسعت دینے پر قائل کرے گا، اور کون سا رکنے پر؟
• کیا ہم یہ کسی مسئلے کو حل کرنے کے لیے خرید رہے ہیں، یا اِس لیے کہ ہم جیسی دوسری کمپنیوں کے پاس یہ ہے؟

خلاصہ

سینئر قیادت سافٹ ویئر کو فنڈ نہیں کرتی۔ وہ ایک ایسے مسئلے کے خاتمے کو فنڈ کرتی ہے جس کی قیمت وہ پہلے سے ادا کر رہی ہے۔ اُس مسئلے کا نام قیادت کے اپنے الفاظ میں لیجیے، اُس کی لاگت کا دیانت دارانہ تخمینہ لگائیے، بتائیے کہ کون مختلف فیصلہ کرے گا، ایک طے شدہ نتیجے کے مقابل ناپے گئے مختصر پائلٹ سے اِسے ثابت کیجیے، اور مرحلہ وار وعدہ مانگیے۔ اگر آپ اُس فیصلے کا نام نہیں لے سکتے جسے پلیٹ فارم بدلے گا، تو سب سے قابلِ اعتبار بزنس کیس وہ ہے جو آپ جمع ہی نہ کرائیں۔