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

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

سب سے پہلے: درخواستیں وصول کرنے کا ایک ہی چینل

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

اس کا مطلب کلائنٹس کو پیغام بھیجنے سے روکنا نہیں ہے۔ اس کا مطلب یہ ہے کہ جسے پیغام ملے، وہ کسی بھی ٹیکنیشن کے روانہ ہونے سے پہلے اسے ورک آرڈر میں بدلنے کا ذمہ دار ہے۔ عملی طور پر، جو کمپنیاں اسے پائیدار بنا لیتی ہیں وہ تین کام ایک ساتھ کرتی ہیں:

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

درخواست نمبر: وہ فیلڈ جس پر باقی سب کچھ ٹکا ہے

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

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

اسٹیٹس اور ذمہ دار شخص: یہ درخواست اس وقت کس کے پاس ہے

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

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

رسپانس ٹائم: تحریری عہد، زبانی وعدہ نہیں

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

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

سائٹ پر کیا درج ہوتا ہے: نوٹس، تصاویر، دستخط

یہ وہ حصہ ہے جس کی قیمت آپ آج نہیں بلکہ مہینوں بعد ادا کرتے ہیں۔ کام کے وقت سائٹ پر تین چیزیں درج کی جاتی ہیں:

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

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

تبدیلیاں: کرنے سے پہلے دستاویز بنائیں

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

ورک آرڈر سے بل اور ادائیگی کی درخواست تک

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

تعمیل کے پہلو سے، سعودی عرب میں ای انوائسنگ کے تحت آپ کو ایسا الیکٹرانک بل جاری کرنا ہوتا ہے جو کسی حقیقی لین دین سے جڑا ہو اور زکوٰۃ، ٹیکس اور کسٹمز اتھارٹی (ZATCA) کے پلیٹ فارم کے ساتھ مربوط ہو۔ جب آپ کے بل کی لائنوں کا ماخذ بند اور دستاویزی ورک آرڈرز ہوں تو تعمیل مہینے کے آخر کا اضافی کام رہنے کے بجائے آپ کے کام کرنے کے طریقے کا ضمنی نتیجہ بن جاتی ہے۔

Origami کا نقطۂ نظر

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

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

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

آگے کیا ہے

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

ذرائع