تبدیلی کے 70 فیصد پروگرام کیوں ناکام ہو جاتے ہیں
زیادہ تر تبدیلی کے پروگرام ناکام ہو جاتے ہیں۔ وہ اپنے اہداف حاصل نہیں کر پاتے۔
میں نے Novartis میں AI اور ERP کی تبدیلیوں کی قیادت کی۔ میں نے حقیقت دیکھی۔ ٹیکنالوجی مشکل حصہ نہیں ہے۔ سافٹ ویئر اکثر ٹھیک کام کرتا ہے۔ لوگ بس اس سے الگ ہو جاتے ہیں۔
جب کوئی پروجیکٹ ناکام ہوتا ہے، تو لیڈرز ڈیٹا یا اسکوپ (scope) کو موردِ الزام ٹھہراتے ہیں۔ یہ محض علامات ہیں۔ اصل وجہ 'ایڈاپشن' (adoption) ہے۔ زیادہ تر کمپنیاں ایڈاپشن کو آخر میں ہونے والی ایک ٹریننگ ایونٹ سمجھتی ہیں۔ اسے شروع سے ہی ڈیزائن کا ایک اصول ہونا چاہیے۔
اگر لوگ کسی ٹول سے بچیں تو اس کی کوئی اہمیت نہیں رہتی۔ میں نے ایسا بہترین سافٹ ویئر دیکھا جس کا استعمال صرف 30 فیصد تھا۔ اس کے بجائے لوگ پرانے اسپریڈ شیٹس (spreadsheets) ہی استعمال کرتے رہے۔
آپ کو اس سافٹ ویئر کا ROI نہیں ملتا جو آپ نے خریدا ہے۔ آپ کو اس سافٹ ویئر کا ROI ملتا ہے جسے لوگ استعمال کرتے ہیں۔
لوگ تبدیلی کی مزاحمت اس لیے کرتے ہیں کیونکہ یہ ایک غیر منافع بخش سودا محسوس ہوتا ہے۔ انہیں کوئی ذاتی فائدہ نظر نہیں آتا، بلکہ صرف زیادہ خطرات اور زیادہ جانچ پڑتال نظر آتی ہے۔
اسے ٹھیک کرنے کے لیے، آپ کو نفسیاتی تحفظ (psychological safety) کی ضرورت ہے۔ لوگوں کو یہ کہنے میں محفوظ محسوس کرنا چاہیے کہ "میں یہ نہیں سمجھتا" یا "یہ عمل خراب ہے۔" تحفظ کے بغیر، لوگ اپنی الجھن چھپاتے ہیں۔ چھپی ہوئی الجھن خاموش 'ورک اراؤنڈز' (workarounds) کی طرف لے جاتی ہے۔ اور یہ متبادل طریقے ناکامی کا باعث بنتے ہیں۔
کامیابی کے لیے اس منصوبے پر عمل کریں:
- کامیابی کی تعریف کریں: کچھ بھی بنانے سے پہلے، یہ لکھ لیں کہ ایک مخصوص کردار (role) میں کیا تبدیلی آئے گی۔ اگر آپ اس شخص کے لیے کامیابی نہیں دکھا سکتے، تو آپ کے پاس کوئی منصوبہ نہیں ہے۔ آپ کے پاس صرف ایک 'رول آؤٹ' (rollout) ہے۔
- شکوک و شبہات رکھنے والوں کو شامل کریں: صرف حامیوں سے بات نہ کریں۔ سب سے زیادہ اعتراض کرنے والے شخص کو ڈیزائن روم میں شامل کریں۔ وہ جلد ہی اصل مسائل تلاش کر لیتے ہیں۔ جب کوئی شکوک کرنے والا منصوبے سے اتفاق کر لیتا ہے، تو دوسرے بھی پیروی کرتے ہیں۔
- ایمانداری سے قیادت کریں: لیڈرز سے کہیں۔ کہ وہ اپنی غلطیوں کا اعتراف کریں۔ ایک باس کا ایک ایماندارانہ لمحہ بہت سے سروے سے زیادہ اعتماد پیدا کرتا ہے۔
- ایمانداری کو انعام دیں: ان لوگوں کا شکریہ ادا کریں جو خراب مراحل کی اطلاع دیتے ہیں۔ وہ آپ کے لیے کوالٹی کنٹرول (quality control) کا کام کر رہے ہوتے ہیں۔
- صحیح چیزوں کی پیمائش کریں: صرف بجٹ اور تاریخوں پر نظر نہ رکھیں۔ اس بات پر نظر رکھیں کہ کتنے لوگ ٹول استعمال کرتے ہیں اور وہ کتنی بار متبادل طریقے (workarounds) استعمال کرتے ہیں۔
- درست کریں اور سب کو بتائیں: جب آپ کوئی مسئلہ حل کریں، تو سب کو بتائیں۔ انہیں دکھائیں کہ آواز اٹھانے سے نظام بدل جاتا ہے۔
اعتماد کو انفراسٹرکچر (infrastructure) کی طرح سمجھیں۔ آپ کو اسے بالکل اپنے ٹیک اسٹیک (tech stack) کی طرح ڈیزائن کرنا چاہیے اور اس کے لیے بجٹ رکھنا چاہیے۔
اپنے آرکیٹیکچر (architecture) کا آڈٹ کرنا بند کریں۔ اپنی ٹیم سے پوچھنا شروع کریں: "اسے آپ کے لیے بہتر بنانے کے لیے کیا کیا جا سکتا ہے، اور آپ مجھے کیا بتانے سے ڈر رہے ہیں؟"
وہ 30 فیصد جو جیت جاتے ہیں، وہی ہیں جو سنتے ہیں۔
ماخذ: https://dev.to/cedricbignet/why-70-of-transformations-fail-and-the-people-first-fix-1ff
اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi