2.5 بہاؤ کی کارکردگی اور جاری کام

جائزہ اور محرک

بہاؤ کی کارکردگی (flow efficiency) کام کے ایک ٹکڑے کے لیے فعال وقت اور کل وقت کا تناسب ہے: اگر کوئی تبدیلی دس گھنٹے فعال طور پر کوڈ کی جاتی، جائزہ لی جاتی، اور ٹیسٹ کی جاتی ہے، لیکن اپنے پورے سفر میں مجموعی طور پر نوے گھنٹے قطاروں میں بیکار پڑی رہتی ہے، تو بہاؤ کی کارکردگی 10 فیصد ہے۔ زیادہ تر سافٹ ویئر ڈیلیوری پائپ لائنز، ایمانداری سے ناپی جائیں تو، 10 فیصد اور 25 فیصد بہاؤ کی کارکردگی کے درمیان کہیں آتی ہیں، جو ان لوگوں کو حیران کرتی ہے جو توقع کرتے ہیں کہ کوشش غالب ہوگی۔ زیادہ تر ڈیلیوری نظاموں میں غالب لاگت یہ نہیں کہ کام کرنے میں کتنا وقت لگتا ہے، بلکہ یہ کہ کام شروع ہونے کا کتنا انتظار کرتا ہے۔

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

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

بنیادی اصول

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

سفارشات

یہ فرض کرنے سے پہلے کہ کوشش رکاوٹ ہے بہاؤ کی کارکردگی ناپیں

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

صریح جاری کام کی حد مقرر کریں اور اسے نظر آنے والے طریقے سے نافذ کریں

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

WIP کی حد کو نظام کی پابندی سمجھیں، انفرادی کوٹہ نہیں

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

صرف یہ نہیں کہ کتنی دیر، بلکہ تحقیق کریں کہ کام کیوں بیکار پڑا ہے

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

ابتدائی بہتری کے بعد WIP کے واپس اوپر رینگنے پر نظر رکھیں

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

سمجھوتے: فوائد اور نقصانات

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

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

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات

ہماری اصل بہاؤ کی کارکردگی، حقیقی سائیکل ٹائم ڈیٹا سے ناپی گئی، کیا ہے، اور کیا وہ عدد ہمیں حیران کرتا ہے؟ زیادہ تر ٹیموں نے اسے کبھی حساب نہیں کیا اور فرض کرتی ہیں کہ یہ نکلنے سے کہیں زیادہ ہے۔ اس موضوع میں کسی اور بات پر بحث کرنے سے پہلے حالیہ تبدیلیوں کا نمونہ لیں اور تناسب ایمانداری سے حساب کریں۔
ابھی ہمارے پاس پوری ٹیم میں اصل جاری کام کتنا ہے، اور کیا گننے سے پہلے کسی کو وہ عدد معلوم تھا؟ زیادہ WIP اکثر صریح طور پر ناپے جانے تک نظر نہیں آتا، کیونکہ ہر فرد صرف اپنا حصہ دیکھتا ہے۔ جو کچھ فی الحال جاری ہے سب گنیں، بشمول وہ کام جسے آج کوئی فعال طور پر ہاتھ نہیں لگا رہا۔
اگر ہم WIP کی حد اپنائیں تو نئی فوری درخواست پر ہمارے ردِعمل کے طریقے میں کیا بدلنا ہوگا؟ یہ سوال وہ حقیقی ادارہ جاتی عادت سامنے لاتا ہے، نیا کام فوراً شروع کرنا، جسے روکنے کے لیے WIP کی حد بنی ہے، اور حد نافذ کرنے کی کوشش کے بعد نہیں، پہلے اس پر بحث کرنا مفید ہے۔
جب ہماری پائپ لائن میں کام بیکار پڑا رہتا ہے تو مخصوص وجہ کیا ہے، اور کیا ہر بار وہی وجہ ہوتی ہے؟ عمومی احساس کہ “چیزیں انتظار کرتی رہتی ہیں” مخصوص، بار بار آنے والی وجہ سے کم مفید ہے: غیر دستیاب جائزہ لینے والا، بک شدہ مشترکہ ماحول، ٹیموں کے درمیان انحصار۔ حالیہ حقیقی مثالوں سے اصل نمونے کا نام لیں۔
کیا ہم نے کبھی WIP کی حد اپنائی اور پھر اسے استثناوں کے ذریعے خاموشی سے گھستے دیکھا؟ یہ بہت عام ہے اور ایمانداری سے بحث کے قابل ہے: پہلے استثنا کا سبب کون سا دباؤ تھا، اور کیا استثنا بغیر کسی کے صریح فیصلے کے نیا معمول بن گئے۔
کیا ہمارے سیاق میں WIP کی حد انفرادی، ٹیم، یا مشترکہ وسیلے (جیسے جائزے کی قطار یا ٹیسٹ ماحول) کی سطح پر لاگو ہونی چاہیے؟ مختلف رکاوٹیں مختلف سطحوں پر حدوں کا تقاضا کرتی ہیں، اور غلط سطح پر حد لاگو کرنا، مشترکہ قطار کی حد کے بجائے انفرادی کوٹے، پوری تکنیک کو غلط لاگو کر سکتا ہے۔

شعبے کا زاویہ

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

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

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

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

مثالیں

بڑا ادارہ۔ ایک مالیاتی خدمات کی کمپنی کی پلیٹ فارم ٹیم صرف بارہ انجینئروں کے ساتھ اٹھارہ ہم وقت پہل کاریاں سنبھال رہی تھی، WIP اور صلاحیت کا تناسب جسے کسی نے اس وقت تک حساب نہیں کیا جب تک انجینئرنگ کے نئے ڈائریکٹر نے براہِ راست مانگا۔ ٹیم کے کام میں بہاؤ کی کارکردگی 12 فیصد سے کم ناپی گئی۔ ٹیم نے ہر دو انجینئروں کے لیے ایک فعال پہل کاری کی صریح WIP کی حد اپنائی، صلاحیت کو پتلا پھیلانا جاری رکھنے کے بجائے کئی کم ترجیح والی پہل کاریوں کو دانستہ روک کر۔ تھرو پٹ، فی سہ ماہی حقیقی طور پر مکمل ہونے والی پہل کاریوں کے طور پر ناپا گیا، دو سہ ماہیوں کے اندر دگنے سے زیادہ ہو گیا، حالانکہ ٹیم کسی بھی لمحے نظر آنے والے طور پر “کم کر رہی” تھی۔

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

کاروباری جواز: محرکات، ROI، اور TCO

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

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

منفی نمونے اور خطرات

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

پختگی کا نمونہ

درجہ 1، آغاز (Initiate): جاری کام ٹریک نہیں ہوتا؛ ٹیمیں کل ہم وقت بوجھ کی کسی نظر کے بغیر نیا کام فوراً شروع کرتی ہیں۔
درجہ 2، ترقی (Develop): کچھ ٹیمیں غیر رسمی بورڈ استعمال کرتی ہیں، لیکن WIP کی حدیں یکساں نافذ نہیں ہوتیں اور بہاؤ کی کارکردگی کا کبھی حساب نہیں ہوتا۔
درجہ 3، معیار بندی (Standardize): ٹیموں کی نظام کی سطح پر صریح، نظر آنے والی WIP کی حدیں ہیں، اور بہاؤ کی کارکردگی حقیقی سائیکل ٹائم ڈیٹا سے دورانیہ وار ناپی جاتی ہے۔
درجہ 4، انتظام (Manage): WIP کی حد کے استثنا کو دانستہ، نظر آنے والے فیصلوں کے طور پر ٹریک کیا جاتا ہے؛ بہاؤ کی کارکردگی کی وقت کے ساتھ گھساؤ کے لیے نگرانی ہوتی ہے اور گرنے پر تحقیق ہوتی ہے۔
درجہ 5، ہم آہنگی (Orchestrate): WIP صرف ٹیم کی نہیں بلکہ پورٹ فولیو کی سطح پر نظر آنے والا اور منظم ہے، اور ادارہ تھرو پٹ کی ان مخصوص بہتریوں کی نشاندہی کر سکتا ہے جو ہم وقت کام دانستہ کم کرنے سے حاصل ہوئیں۔

بحث کے لیے خیالات

ہماری اصل بہاؤ کی کارکردگی، حقیقی ڈیٹا سے ایمانداری سے حساب کی گئی، کیا ہے؟
ہمارے پاس اس بحث سے پہلے کسی کے گنے بغیر فی الحال کتنا جاری کام ہے؟
حقیقی WIP کی حد نافذ کرنے کے لیے ہمیں کس چیز کو “نہ” کہنا پڑے گا؟
ہماری پائپ لائن میں کام کے بیکار پڑے رہنے کی سب سے عام وجہ کون سی ہے؟
ہمارے ادارے میں پورٹ فولیو کی سطح کا WIP کہاں غیر مرئی ہے اور شاید بہت زیادہ ہے؟

اہم نکات

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

حوالہ جات اور مزید مطالعہ

The Principles of Product Development Flow, by Donald G. Reinertsen (پروڈکٹ کی ترقی میں قطار کا نظریہ، بیچ کا سائز، اور WIP کی حدیں)۔
Kanban: Successful Evolutionary Change for Your Technology Business, by David J. Anderson (سافٹ ویئر ٹیموں کے لیے WIP کی حدوں اور بہاؤ پر بنیادی متن)۔
Actionable Agile Metrics for Predictability, by Daniel S. Vacanti (بہاؤ کی کارکردگی کی پیمائش اور بہاؤ پر مبنی پیش گوئی)۔
The Goal, by Eliyahu M. Goldratt (پابندیوں کا نظریہ اور مقامی مصروفیت اور نظام کے تھرو پٹ کے درمیان خلافِ توقع تعلق)۔