قانون لیتل: چرا کاهش زمان تحویل بدون محدود کردن کارهای هم‌زمان ناممکن است؟

در اول ژوئن ۱۹۶۱، جان دی.سی. لیتل مقاله‌ای با عنوان «اثباتی بر فرمول صف‌بندی: L = λW» در نشریه معتبر Operations Research منتشر کرد. این استاد مؤسسه فناوری ماساچوست (MIT) قطعیتی ریاضیاتی را پایه گذاشت که برای دهه‌ها چارچوب مدیریت عملیات را شکل داده است.[1]

این قضیه اثبات کرد که میانگین بلندمدت اقلام حاضر در یک سیستم پایدار، برابر است با حاصل‌ضرب میانگین بلندمدت نرخ ورودی در میانگین زمانی که هر قلم در سیستم سپری می‌کند؛ اصلی که پاسخی ساختاری به ریشه تأخیرها در هر فرایند دارای محدودیت داد.[1]

سامانه کانبان تول (Kanban Tool) در این‌باره می‌نویسد: «وقتی نرخ ورود اقلام از نرخ سرویس‌دهی فراتر برود، صف شکل می‌گیرد. صف‌های مهارنشده تاخیرهای غیرقابل‌پیش‌بینی به بار می‌آورند، به‌ویژه هنگام جهش ورودی‌ها؛ در حالی که تعیین درست محدودیت کار در جریان (WIP)، سیستم را مهار می‌کند، جلوی انباشت کار را می‌گیرد و زمان چرخه تعیین‌شده را حفظ می‌نماید.»

در مدیریت نوین کسب‌وکار، این فرمول به زبانی کاملاً عملیاتی ترجمه می‌شود: کار در جریان برابر است با نرخ خروجی ضرب‌در زمان تحویل. به بیانی دیگر، زمان تحویل حاصل تقسیم کار در جریان بر نرخ خروجی است؛ یک نسبت ریاضی خلل‌ناپذیر که بر تمام محیط‌های تولیدی و خدماتی حاکم است.

این رابطه حکم می‌کند که یک سازمان نمی‌تواند بدون بالا بردن نرخ تکمیل یا اعمال محدودیت سفت‌وسخت بر کارهای هم‌زمان، زمان تحویل را کوتاه کند. این جبر ریاضی فارغ از نوع صنعت، نوع محصول، یا پیچیدگی گردش کار داخلی پابرجا می‌ماند.

مکانیک ریاضی جریان صف

این فرمول برای ایفای نقش ابزار عارضه‌یابی به سه متغیر مشخص وابسته است. متغیر اول، «کار در جریان» (WIP) است؛ یعنی کل موجودی اقلام ناتمام که در هر لحظه مشخص درون مرزهای تعریف‌شده سیستم قرار دارند.[2]

متغیر دوم، «نرخ خروجی» (Throughput) است که به میانگین نرخ خروج کارهای تکمیل‌شده از سیستم اطلاق می‌شود. در یک فضای کاملاً پایدار، این نرخ خروج دقیقاً معادل نرخ ورود کارهای جدید به صف پردازش است.[2]

متغیر نهایی، «زمان تحویل» (Lead Time) است که مدت‌زمان حضور کامل یک کار در سیستم را از بدو ورود تا لحظه خروج می‌سنجد. این شاخص هم زمان پردازش فعال و هم کل زمان معطلی در صف برای آزادسازی منابع را در بر می‌گیرد.[2]

پلتفرم آموزشی کورسرا (Coursera) این اصل را در قالب یک سناریوی درمانگاهی توضیح می‌دهد: «یک درمانگاه شلوغ فوریت‌های پزشکی ممکن است هم‌زمان ۲۰ بیمار در ساختمان داشته باشد. هر ۱۵ دقیقه یک بیمار جدید وارد می‌شود و هر کدام حدود ۵ ساعت در ساختمان می‌ماند.»[2]

در این مثال پزشکی، نرخ ورود دقیقا ۴ بیمار در ساعت است. با ضرب آن در میانگین زمان حضور پنج ساعته، سیستم به لحاظ ریاضی بار پیوسته‌ای معادل ۲۰ بیمار هم‌زمان (کار در جریان) را در هر لحظه به فضای درمانگاه تحمیل می‌کند.[2]

اگر مدیریت درمانگاه قصد داشته باشد بدون استخدام پزشک جدید و بدون افزایش توان خروجی، زمان انتظار را به ۲٫۵ ساعت کاهش دهد، چاره‌ای جز رساندن تعداد بیماران هم‌زمان به ۱۰ نفر ندارد. این متغیرها طبق معادله به‌صورت صلب به یکدیگر گره خورده‌اند.[2]

سراب سرعت در مدیریت عملیات

مدیران سازمان‌ها غالباً تلاش می‌کنند با دستور شتاب‌بخشی و هم‌زمان کلید زدن ابتکارات جدید، سرعت تحویل پروژه‌ها را بالا ببرند. قانون لیتل ثابت می‌کند چنین رویکردی از نظر ریاضی نتیجه‌ای کاملاً برعکس می‌دهد، زیرا افزایش کارهای هم‌زمان فقط زمان نهایی تحویل را باد می‌کند.[2]

کورسرا می‌افزاید: «اگر مدیریت خواهان نصف شدن آن رقم است، دو راه بیشتر پیش رو ندارد: کارها را سریع‌تر تمام کند یا کارهای کمتری تحویل بگیرد. میانگین زمان چرخه را به یک هفته کاهش دهید، و کار در جریان به ۱۰ کاهش می‌یابد.»[2]

هنگامی که سازمانی تعداد پروژه‌های فعالش را بدون رشد متناظر در نرخ تحویل زیاد می‌کند، زمان تحویل تک‌تک پروژه‌ها ناگزیر طولانی‌تر می‌شود. کار مازاد صرفاً در صفی طولانی در انتظار آزاد شدن منابعِ گرفتار می‌نشیند.

پلتفرم لاگ‌راکت (LogRocket) گزارش می‌دهد: «سازمان‌ها می‌توانند با تحلیل نرخ‌های ورودی گذشته و میانگین زمان حضور در سیستم، پیش‌بینی کنند که تغییر این متغیرها چه اثری بر تعداد اقلام موجود در سیستم خواهد داشت.» مدیران باید برای درک ظرفیت واقعی عملیات، هر سه متغیر را هم‌زمان پایش کنند.

این قضیه برملا می‌کند که افزودن موجودی و کار بیشتر به یک سیستم دارای محدودیت، بیش از آنکه خروجی را بالا ببرد، به زمان خواب و معطلی اضافه می‌کند. برای تسریع گردش کار، سازمان‌ها باید گلوگاه واقعی را شناسایی کنند، نه اینکه بار کارهای جدید را سنگین‌تر سازند.

کاربست در اقتصاد دانشی و نرم‌افزار

قانون لیتل اگرچه در آغاز برای کارخانه‌ها و خرده‌فروشی‌ها مطرح شد، اکنون به پایه ریاضی مهندسی نرم‌افزار نوین بدل شده است. تیم‌های چابک برای مدیریت جریان کار دیجیتال خود در سامانه‌های بصری کانبان که تک‌تک قابلیت‌های در دست ساخت را ردگیری می‌کنند، بر همین فرمول متکی هستند.

پلتفرم مدیریت پروژه نیو (Nave) توضیح می‌دهد: «در کانبان، قانون لیتل سه سنجه پایه یعنی نرخ خروجی، زمان چرخه و کار در جریان را در قالب یک فرمول ساده به هم پیوند می‌زند. درک پیوند میان این سنجه‌های کانبان، امکان کالبدشکافی و تحلیل فرایندهای کاری را فراهم می‌آورد.»

تیم‌های توسعه نرم‌افزار محدودیت‌های سفت‌وسختی بر کار در جریان در تابلوهای کاری خود اعمال می‌کنند. آن‌ها با سقف گذاشتن بر تعداد کدهایی که هم‌زمان نوشته یا تست می‌شوند، از نظر ریاضی کاهش زمان تحویل را حتمی می‌سازند.

اگر یک تیم مهندسی در هر هفته ۱۰ تسک را به پایان برساند و هم‌زمان ۲۰ تسک باز داشته باشد، زمان چرخه میانگین دقیقاً روی دو هفته قفل می‌شود. پذیرش ۵ کار جدید بدون افزایش نرخ تکمیل، این زمان چرخه را به ۲٫۵ هفته پرتاب می‌کند.[2]

سامانه نیو تأکید می‌کند: «محدود کردن کار در جریان باعث می‌شود نرخ ورودی و خروجی تسک‌ها تقریباً هم‌تراز بماند تا اعمال قانون لیتل امکان‌پذیر شده و نتایج دقیقی به دست آید.» این ثبات برای داشتن قدرت پیش‌بینی کاملاً ضروری است.

مدیریت محصول نیز برای زمان‌بندی چرخه‌های انتشار نرم‌افزار به همین محاسبات صف وابسته است. طبق گزارش لاگ‌راکت، این قضیه مکرراً برای مدیریت جنبه‌های گوناگون اجرای پروژه، از جمله تخصیص بهینه منابع و ظرفیت‌سنجی میان چندین تیم مهندسی، به کار می‌رود.

اهمیت تعیین دقیق مرزهای سیستم

میزان دقت این قضیه تماماً به چگونگی مرزبندی سیستم توسط سازمان بستگی دارد. محاسبه تنها زمانی نتایج معتبر می‌دهد که برای هر سه متغیر، دقیقاً همان نقاط ورودی و خروجی مشترک در نظر گرفته شده باشند.

مجموعه پپیت دیتا (Pepite Data) یادآور می‌شود: «این فرمول برای هر مرزی که دور فرایند بکشید برقرار است و همین ویژگی آن را برای ارزیابی کارآمد می‌کند؛ از استخر ریسه‌ها (Thread Pool) و پایگاه داده گرفته تا یک گروه مصرف‌کننده کافکا یا کل یک پلتفرم یکپارچه.»

در زیرساخت‌های دیجیتال، این قانون بر پردازش با سرعت بالای تراکنش‌ها با همان دقتی حاکم است که بر انبارهای فیزیکی حکومت می‌کند. پپیت دیتا محاسبه می‌کند: «اگر سرویسی ۲,۰۰۰ درخواست در ثانیه را با میانگین زمان توقف ۵۰ میلی‌ثانیه پاسخ دهد، میانگین درخواست‌های حاضر درون سیستم برابر است با ۲,۰۰۰ ضرب‌در ۰٫۰۵۰ که معادل ۱۰۰ درخواست می‌شود.»

آن ۱۰۰ درخواست جاری باید در هر میلی‌ثانیه مفروض، جایی در محدوده تعیین‌شده سیستم حضور عینی داشته باشند؛ خواه در صف اپلیکیشن، خواه در مجموعه پردازنده‌ها یا بافر هسته سیستم‌عامل، اما منطق ریاضی حضور دائمی آنها را اجتناب‌ناپذیر می‌داند.

اگر گزارش آزمون کارایی یک سامانه رقمی از خروجی و تاخیر بدهد که در این تساوی صدق نکند، آن اندازه‌گیری از ریشه نادرست است. گزارش احتمالاً معیارهای مربوط به مرزها یا بازه‌های زمانی متفاوتی را در هم آمیخته و ادعاهای عملکردی آن فاقد اعتبار است.

پیش‌شرط گریزناپذیر: پایداری سیستم

محدودیت عمده این قضیه، الزام قطعی آن به پایدار بودن سیستم است. در درازمدت، میانگین ورود کار به فرایند باید کاملاً با میانگین اقلام خارج‌شده هم‌خوان باشد تا محاسبات روی کاغذ اعتبار داشته باشند.[1]

اگر آهنگ ورودی همواره از توان خروجی سبقت بگیرد، سامانه دچار ناپایداری ساختاری می‌شود؛ کار در جریان تا بی‌نهایت باد می‌کند و زمان تحویل چنان کش می‌آید که سیستم سرانجام زیر بار انباشته خرد خواهد شد.

هنگام شوک‌های مقطعی تقاضا یا قطعی‌های فنی، این رابطه توان پیش‌بینی رفتار کوتاه‌مدت را ندارد. این اصل یک قانون میانگین‌محور در افق بلندمدت است که ظرفیت ساختاری را می‌سنجد، نه تلاطم‌های گذرا و بحران‌های آنی روزمره را.[1]

منطق ریاضی مدیران را وادار می‌کند به‌جای اتکا به شعار و تلاش مضاعف، با سقف واقعی توان خود روبرو شوند. سنجه قابل‌سنجش برای هر تیمی که زیر بار کار مانده، شمار کارهای هم‌زمانی است که متوقف می‌کند؛ چراکه زمان تحویل همواره بر نسبت تعهدات باز به کارهای تمام‌شده متکی می‌ماند.[3]