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

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

خریداری کی درخواست: وہ دستاویز جس پر اس کے بعد کی ہر چیز ٹکی ہوتی ہے

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

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

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

منظوری کا میٹرکس: صرف رقم کافی نہیں

منظوری کا میٹرکس ایک جدول ہے جو ایک سوال کا جواب دیتا ہے: اس درخواست کو ہاں کون کہہ سکتا ہے؟ سب سے سادہ میٹرکس ایک ہی محور پر بنتا ہے، یعنی رقم: ایک حد تک شعبے کا مینیجر منظوری دیتا ہے، اس سے اوپر فنانس مینیجر، اور اس سے بھی اوپر مالک۔ رقم ایک درست محور ہے، لیکن خریداری کی قسم اس سوال کو بدل دیتی ہے جس کا جواب منظوری دینے والا دے رہا ہوتا ہے:

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

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

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

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

دو چور راستے جو سسٹم کو بند کرنے ہوں گے

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

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

حل کا مطلب کاغذ اور قلم والے دستخطوں کی طرف لوٹنا نہیں ہے۔ الیکٹرانک لین دین کا قانون الیکٹرانک لین دین، ریکارڈز اور دستخطوں کو اپنی مقرر کردہ شرائط کے تحت پابند کرنے والا اثر دیتا ہے (شق 5)، اور کسی الیکٹرانک لین دین کی ثبوتی قدر کا اندازہ لگاتے وقت یہ دیکھتا ہے کہ ریکارڈ بنانے، محفوظ کرنے یا بھیجنے کے لیے استعمال کیا گیا طریقہ کتنا قابل اعتماد ہے، اور کیا اس میں تبدیلی کی جا سکتی تھی (شق 9(4))۔ WhatsApp منظوری کا مسئلہ یہ نہیں کہ وہ الیکٹرانک ہے؛ مسئلہ یہ ہے کہ وہ اس درخواست سے الگ ہے جس کی وہ منظوری دیتی ہے۔ اس لیے منظوری سسٹم کے اندر خود درخواست پر ہوتی ہے، جس میں منظوری دینے والے کا نام، وقت، رقم اور منظور شدہ ورژن درج ہوتا ہے، اور اگر بعد میں درخواست کی مقدار یا رقم بدل جائے تو وہ دوبارہ منظوری کے لیے جاتی ہے۔ WhatsApp اطلاع کا چینل بنا رہتا ہے: منظوری دینے والے کو درخواست کے لنک کے ساتھ ایک نوٹیفکیشن ملتا ہے اور وہ لیپ ٹاپ کھولے بغیر اپنے فون سے اسے منظور کر دیتا ہے، یوں سست منظوری اسے نظرانداز کرنے کی وجہ نہیں رہتی۔

فوری خریداری: چور راستے کے بجائے ایک اعلانیہ راستہ

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

دیانت دارانہ طریقہ ایسا سسٹم ہے جو تسلیم کرے کہ ہنگامی حالات ہوتے ہیں اور انہیں واضح شرائط کے ساتھ ایک اعلانیہ راستہ دے:

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

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

Origami کا نقطۂ نظر

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

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

اس ہفتے کے لیے ایک مشق: اپنا میٹرکس ایک صفحے پر بنائیں

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

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

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

اگلے حصے میں

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

ماخذ