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

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

مزاحمت ضد نہیں، خطرے کا حساب ہے

پہلے ہفتے میں سب سے پہلے آپ کا سامنا ٹیم کی ہچکچاہٹ سے ہوتا ہے۔ عام غلطی یہ ہے کہ مالک اس ہچکچاہٹ کو تبدیلی کی مخالفت یا سستی سمجھ لیتا ہے اور اس کا جواب دباؤ سے دیتا ہے۔ عام طور پر یہ دونوں میں سے کچھ بھی نہیں ہوتا۔

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

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

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

پرانی فائل کی طرف خاموش واپسی

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

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

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

وہ کمیاں جو منتقلی کے بعد سامنے آتی ہیں، پہلے نہیں

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

اس مرحلے پر عام طور پر جو سامنے آتا ہے:

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

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

ایک بار دی گئی تربیت کافی نہیں

مشکلات کا شکار منصوبوں میں سب سے زیادہ دہرایا جانے والا طرز یہ ہے کہ تربیت لانچ کے دن ایک ہی نشست کی صورت میں دی جاتی ہے، جس میں سب شریک ہوتے ہیں اور پورے سسٹم کو شروع سے آخر تک دکھایا جاتا ہے۔ پھر سب اپنی میز پر لوٹتے ہیں اور زیادہ تر بھول چکے ہوتے ہیں، کیونکہ انہوں نے اسے ضرورت پڑنے سے پہلے سنا تھا۔

جو متبادل کام کرتا ہے وہ تین اصولوں پر قائم ہے:

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

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

Origami کا نقطۂ نظر

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

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

تیس دن کا منصوبہ

یہ ایک ایسا منصوبہ ہے جسے آپ لکھے کے مطابق چلا سکتے ہیں، اور اس کی سب سے اہم خصوصیت یہ ہے کہ ہر مرحلے کا ایک اعلان شدہ اختتام ہے:

  • دن 1-7: محدود متوازی کام۔ کام سسٹم اور پرانی فائل دونوں میں صرف ایک وجہ سے درج کیا جاتا ہے — موازنہ۔ ہفتے کے آخر میں ایک چھوٹا نمونہ لیں، دونوں اعداد کا موازنہ کریں، اور ہر فرق کو اس کے حجم سے نہیں بلکہ اس کی وجہ سے درج کریں۔
  • دن 8: پرانی فائل صرف پڑھنے کے قابل بن جاتی ہے۔ یہ منصوبے کا سب سے اہم قدم ہے۔ فائل دیکھنے کے لیے دستیاب رہتی ہے اور کوئی اس میں نہیں لکھتا۔ بغیر اعلان شدہ اختتامی تاریخ کے متوازی کام غیر معینہ مدت تک چلتا رہتا ہے، اور یہ ہمیشہ پرانی فائل کی جیت پر ختم ہوتا ہے کیونکہ وہ آسان ہے۔
  • دن 8-14: دوسری تربیت اور کمیاں دور کرنا۔ ہر ٹیم کے لیے ان سوالوں پر ایک مختصر نشست جو واقعی سامنے آئے، اور کمیوں کی فہرست کے سرفہرست پانچ نکات کو بند کرنا۔
  • دن 15-21: استعمال ناپیں۔ دیکھیں کہ کون واقعی سسٹم استعمال کر رہا ہے اور کون نہیں، اور دیر سے درج ہونے والے ہر لین دین کے لیے پوچھیں کہ کیوں۔ جو آپ سیکھتے ہیں وہ راستے کی وضاحت کے بارے میں ایک اشارہ ہے، انفرادی نظم و ضبط کے بارے میں نہیں۔
  • دن 22-30: استحکام اور جائزہ۔ باقی مشاہدات بند کریں، صرف سسٹم سے پہلی ماہانہ رپورٹ تیار کریں، اور ٹیم کے سربراہوں کے ساتھ آدھا گھنٹہ بیٹھ کر پہچانیں کہ اب بھی سسٹم کے باہر کیا ہو رہا ہے اور کیوں۔

کامیابی کا دیانت دارانہ پیمانہ سروے میں ٹیم کا اطمینان یا استعمال ہونے والی اسکرینوں کی تعداد نہیں ہے۔ یہ ایک واحد لمحہ ہے: کوئی بغیر کہے پرانی فائل کھولنا بند کر دیتا ہے۔ اس وقت سسٹم وہ منصوبہ نہیں رہتا جسے آپ سنبھال رہے ہیں — وہ کمپنی کے کام کرنے کا طریقہ بن جاتا ہے۔

سلسلے کا اختتام

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

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

ذرائع