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

سسٹم سے پہلے عمل: وہ ناکامی جو انسٹالیشن سے پہلے شروع ہوتی ہے

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

کامیابی کسی بھی سسٹم کے انتخاب سے پہلے شروع ہوتی ہے: اپنے عمل کو واضح کریں اور دستاویزی شکل دیں، اور سسٹم سے کوئی عمل چلانے کو کہنے سے پہلے ہر عمل کے لیے ایک ہی طریقے پر اتفاق کریں۔ عمل کو واضح کرنے میں لگایا گیا وقت بعد میں نفاذ اور کسٹمائزیشن میں اس سے کئی گنا زیادہ وقت بچاتا ہے۔

اندرونی مالک: مالک کے بغیر پروجیکٹ بھٹک جاتا ہے

ERP ہر شعبے کو چھوتا ہے، اسی لیے اسے کمپنی کے اندر ایک ایسے شخص کی ضرورت ہوتی ہے جو واقعی پروجیکٹ کا مالک ہو: فیصلے کرے، شعبوں کے درمیان تنازعات حل کرے، اور وینڈر کے ساتھ فالو اپ کرے۔ وینڈر نفاذ کا شراکت دار ہے؛ وہ آپ کے پروجیکٹ کا مالک نہیں اور آپ کی ترجیحات کو اس طرح نہیں جانتا جیسے آپ جانتے ہیں۔ جو پروجیکٹ کسی واضح اندرونی مالک کے بغیر چھوڑ دیا جائے وہ بغیر فیصلوں کے اجلاسوں کا ایک سلسلہ بن جاتا ہے: وہ طول پکڑتا ہے اور مرجھا جاتا ہے۔

کامیابی: حقیقی اختیار اور مخصوص وقت رکھنے والا اندرونی مالک مقرر کریں، نہ کہ ایسا ملازم جس کے روزمرہ کاموں کے حاشیے پر پروجیکٹ کا اضافہ کر دیا گیا ہو۔ یہ مالک وینڈر کے سامنے کمپنی کی واحد آواز ہے، اور اس بات کی ضمانت ہے کہ فیصلے طے ہوں گے، ملتوی نہیں ہوں گے۔

صاف ڈیٹا اور مرحلہ وار نفاذ

دو تکنیکی وجوہات درست بجٹ والے پروجیکٹس کو ڈبو دیتی ہیں:

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

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

تربیت اور تبدیلی کا انتظام: وہ پہلو جو نتیجے کا فیصلہ کرتا ہے

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

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

Origami کا نقطۂ نظر

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

خلاصہ: سلسلے کا اختتام اور ایک نئی نسل کا آغاز

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

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

ذرائع

  • زکوٰۃ، ٹیکس اور کسٹمز اتھارٹی (ZATCA) — ای انوائسنگ (Fatoora) ایک ایسی ذمہ داری کے طور پر جسے ہر مرحلہ وار نفاذ کو مدنظر رکھنا چاہیے: https://zatca.gov.sa
  • سعودی ڈیٹا اور مصنوعی ذہانت اتھارٹی (SDAIA) — ذاتی ڈیٹا کے تحفظ کا قانون (PDPL) اور منتقلی کے دوران ڈیٹا پر کنٹرولز: https://sdaia.gov.sa
  • سعودی وژن 2030 — ڈیجیٹل تبدیلی اور چھوٹے اور درمیانے کاروباروں کو بااختیار بنانا: https://www.vision2030.gov.sa