تفاوت زمان انجام (Lead Time) و زمان چرخه (Cycle Time)
چرا با وجود تلاش زیاد کارکنان، مشتری همچنان دیر به نتیجه می‌رسد؟ پاسخ را در تفاوت این دو شاخص کلیدی پیدا کنید.
شاید برای شما هم پیش آمده باشد که اعضای تیم با تمام توان مشغول کار باشند، اما پروژه‌ها، درخواست‌ها و خدمات همچنان دیر به دست مشتری برسند. در چنین شرایطی اولین واکنش معمولاً این است:
«باید سریع‌تر کار کنیم.»
اما آیا واقعاً مشکل، سرعت انجام کار است؟ در بسیاری از فرایندها پاسخ خیر است. بخش قابل‌توجهی از زمانی که مشتری منتظر دریافت نتیجه است، صرف انجام کار نمی‌شود؛ درخواست در صفها، کارتابل‌ها، انتظار برای تأیید یا فاصله میان فعالیت‌ها متوقف می‌ماند.
برای پیدا کردن این اتلاف‌های پنهان باید تفاوت چهار مفهوم را بشناسیم: Lead Time، Cycle Time، Processing Time و Waiting Time.
این مقاله بر پایه ۳ پروژه واقعیِ اجراشدهٔ ما نوشته شده است
هر مفهومی که در ادامه می‌خوانید — Lead Time، Cycle Time، SLA، WIP — دقیقاً همان چیزی است که تیم ما در ۳ پروژهٔ واقعی زیر اندازهگیری، تحلیل و بهبود داده است.
یکی از بزرگ‌ترین نهادهای زیرساخت بازار سرمایه ایران
زمان‌سنجی فرایند توقیف سهام
اندازهگیری دقیق سایکل‌تایم، لیدتایم و SLA برای هر فعالیت از فرایند توقیف سهام، فعالیت‌به‌فعالیت.
زمان‌سنجی فرایند استعلام توقیف
تحلیل بار کاری و شکاف سایکل‌تایم/لیدتایم در فرایند پاسخگویی به استعلام‌های مراجع قضایی و نهادهای بیرونی.
بازطراحی و اتوماسیون ۸ فرایند در «سمات»
بازطراحی، مکانیزاسیون و پایش SLA برای ۸ فرایند کلیدی، از توقیف سهام تا تسویهٔ فروش، در یک برنامهٔ تحول فرایندی کامل.
یک مثال ساده؛ کار ۳۰ دقیقه‌ای که ۲۱۰ دقیقه طول می‌کشد!
فرض کنید یک درخواست ساعت ۸ صبح وارد سازمان می‌شود. درخواست ابتدا ۱۲۰ دقیقه در صف می‌ماند تا کارشناس بتواند رسیدگی به آن را شروع کند. کارشناس سپس ۳۰ دقیقه واقعاً روی درخواست کار میکند. پس از انجام کار، درخواست برای تأیید مدیر ارسال می‌شود و ۶۰ دقیقه دیگر در کارتابل مدیر منتظر می‌ماند. در نهایت درخواست پس از ۲۱۰ دقیقه تکمیل و نتیجه به مشتری تحویل داده می‌شود.
حالا این درخواست چقدر زمان برده است؟ ۳۰ دقیقه یا ۲۱۰ دقیقه؟ پاسخ به این سؤال بستگی دارد به اینکه دقیقاً چه چیزی را اندازه می‌گیریم.
زمان انجام (Lead Time) در برابر زمان چرخه (Cycle Time)
پیش از هر تصمیمی برای بهبود فرایند، باید این دو شاخص را دقیق از هم تفکیک کنیم.
زمان انجام (Lead Time) چیست؟
Lead Time کل زمان سپری‌شده از ورود درخواست به جریان تا تحویل نتیجه نهایی است. به زبان ساده، به این سؤال پاسخ میدهد: «مشتری از زمان ثبت درخواست تا دریافت نتیجه چقدر منتظر مانده است؟»
از نگاه مشتری اهمیتی ندارد درخواست چند دقیقه در دست کارشناس بوده، چه مدت در صف مانده یا چند بار بین واحدهای مختلف جابه‌جا شده است؛ او کل زمان سپری‌شده تا دریافت نتیجه را تجربه میکند. به همین دلیل Lead Time یکی از مهمترین شاخص‌ها برای سنجش عملکرد انتها‌به‌انتهای فرایند و تجربه مشتری است.
در مثال ما: Lead Time = ۲۱۰ دقیقه
زمان چرخه (Cycle Time) چیست؟
Cycle Time مدت‌زمان عبور یک آیتم کاری از نقطه شروع یک چرخه مشخص تا پایان همان چرخه است. برای مثال، اگر در یک سیستم مدیریت کار، چرخه را از لحظه ورود درخواست به وضعیت In Progress تا رسیدن به Done تعریف کنیم، Cycle Time فاصله زمانی میان همین دو نقطه خواهد بود.
بنابراین برای اندازهگیری صحیح Cycle Time باید ابتدا مشخص کنیم چرخه موردنظر دقیقاً از کجا شروع و کجا تمام می‌شود؛ این نکته به‌خصوص در تحلیل فرایندهای سازمانی اهمیت زیادی دارد.
Processing Time (Touch Time) و Waiting Time چیست؟
یکی از اشتباهات رایج این است که Cycle Time را همیشه معادل «زمانی که کارشناس واقعاً روی درخواست کار میکند» در نظر بگیریم. برای این مفهوم، اصطلاح Processing Time یا Touch Time دقیق‌تر است: مدت زمانی که واقعاً کار ارزش‌آفرین یا پردازش روی درخواست انجام می‌شود. در مثال ما، Processing Time برابر ۳۰ دقیقه است.
| شاخص | به چه سؤالی پاسخ میدهد؟ |
|---|---|
| Lead Time | مشتری از ابتدا تا انتها چقدر منتظر است؟ |
| Cycle Time | عبور کار از چرخه تعریف‌شده چقدر طول می‌کشد؟ |
| Processing Time | واقعاً چقدر روی درخواست کار انجام شده است؟ |
| Waiting Time | درخواست چقدر بدون انجام کار منتظر مانده است؟ |
⏳ زمان انتظار (Waiting Time)؛ اتلافی که دیده نمی‌شود
Waiting Time مدت زمانی است که درخواست در سیستم حضور دارد، اما کار مؤثری روی آن انجام نمی‌شود؛ مثلاً ماندن در صف کارشناس، انتظار در کارتابل مدیر، انتظار برای تأیید، انتظار برای دریافت اطلاعات، توقف بین دو واحد و انتظار برای تصمیم‌گیری. در یک مدل ساده می‌توان نوشت:
البته در فرایندهای واقعی ممکن است زمان انتقال، بازکاری و انواع دیگری از زمان نیز وجود داشته باشد. به همین دلیل، هنگام اندازهگیری شاخص‌ها باید نقاط شروع و پایان هر کدام به‌طور دقیق تعریف شوند.
وقتی Cycle Time و Lead Time را در فرایند واقعی «توقیف سهام» اندازه گرفتیم
در پروژهٔ کارسنجی فرایند توقیف سهام که برای شرکت سپرده‌گذاری مرکزی اوراق بهادار و تسویه وجوه اجرا کردیم، فعالیت‌های فرایند توقیف و اجرای توقیف به‌صورت جزء‌به‌جزء زمان‌سنجی شدند. در بازهٔ سه‌ماههٔ بررسی‌شده (اردیبهشت تا تیر)، مجموعاً ۳,۵۴۴ درخواست توقیف و ۴,۹۲۲ اجرای توقیف ثبت شد. جدول زیر بخشی از خروجی واقعی این کارسنجی است (بدون هیچ نام شخص یا اطلاعات محرمانه‌ای) و دقیقاً همان شکاف میان Cycle Time و Lead Time را که در بالا توضیح دادیم، با عدد واقعی نشان میدهد.
| فعالیت | واحد مسئول | سایکل‌تایم واقعی (دقیقه) | لیدتایم واقعی (دقیقه) | SLA تعریف‌شده (دقیقه) |
|---|---|---|---|---|
| ثبت اطلاعات حقوقی درخواست | حقوقی | ۶٫۸ | ۷۹ | ۷۵ |
| بررسی و تنظیم نامه صادره | حقوقی | ۸٫۱ | ۸۲ | ۸۰ |
| بررسی وضعیت کد بورسی و دارایی | عملیات | ۷٫۹ | ۲۹ | ۲۵ |
| تعیین دین سهام‌های موردنظر برای توقیف | حقوقی | ۲۰٫۷ | ۵۹ | ۵۵ |
| ثبت نظر کارشناس مسئول حقوقی | حقوقی | ۱٫۰ | ۲۰۲ | ۲۵۰ |
| کنترل نهایی عملیات توقیف سهام | عملیات | ۴٫۶ | ۱۸۳ | ۱۲۰ |
| بررسی نهایی و درج ارزش ریالی | حقوقی | ۷٫۷ | ۱۱۴ | ۸۰ |
منبع: گزارش نهایی زمان‌سنجی فرایند توقیف — شرکت سپرده‌گذاری مرکزی اوراق بهادار و تسویه وجوه (بدون نام اشخاص) — بازهٔ بررسی اردیبهشت تا تیر
💡 چه چیزی از این جدول واقعی می‌فهمیم؟
در بیشتر ردیف‌ها، Cycle Time واقعی (زمان خالص کار) تنها چند دقیقه است، اما Lead Time هر فعالیت ده‌ها برابر آن اندازهگیری شده است. برای نمونه «ثبت نظر کارشناس مسئول حقوقی» فقط ۱ دقیقه زمان پردازش خالص دارد، اما در عمل ۲۰۲ دقیقه طول کشیده تا در نوبت آن کارشناس قرار بگیرد. همین شکاف است که در تحلیل فرایندهای واقعی، مهمترین فرصت بهبود را نشان میدهد — دقیقاً همان الگویی که در مثال ۲۱۰ دقیقه‌ای دیدیم.
📈 نتیجهٔ این پروژه در فاز بعدی تحول فرایندی
بر اساس همین کارسنجی، فرایند توقیف در فاز بعدی پروژهٔ تحول فرایندی (پروژهٔ ۳) بازطراحی و بخشی از آن با وب‌سرویس اتوماسیون شد. نتیجه؟ میانگین زمان انجام فرایند توقیف از ۴٫۷۳ روز به ۱٫۹۸ روز رسید — ۵۸٪ کاهش، با حذف حدود ۳ ساعت از زنجیرهٔ فرایند فقط با یک وب‌سرویس.
پروژهٔ دوم: کارسنجی فرایند «استعلام توقیف»
در کنار فرایند توقیف، فرایند مجزای «استعلام توقیف» (پاسخگویی به استعلام‌های مراجع قضایی و نهادهای بیرونی دربارهٔ وضعیت توقیف سهام) نیز به‌طور کامل و مستقل کارسنجی شد. در بازهٔ سه‌ماهه، ۹۴۴ استعلام بررسی شد (اردیبهشت ۳۲۰، خرداد ۳۴۹، تیر ۲۷۵ مورد).
| فعالیت | واحد مسئول | سایکل‌تایم واقعی (دقیقه) | لیدتایم واقعی (دقیقه) | SLA تعریف‌شده (دقیقه) |
|---|---|---|---|---|
| بررسی اطلاعات حقوقی استعلام | حقوقی | ۱٫۵ | ۱۵۳ | ۱۳۰ |
| تنظیم پیش‌نویس نامه استعلام از مرجع | حقوقی | ۶٫۷ | ۵۷ | ۶۰ |
| استخراج اطلاعات بخش عملیات | عملیات | ۶٫۲ | ۱۷۴ | ۸۰ |
| بررسی اطلاعات بخش عملیات | عملیات | ۲٫۴ | ۶۹ | ۲۰ |
| بررسی اطلاعات و تنظیم پیش‌نویس نامه | حقوقی | ۵٫۷ | ۲۷۱ | ۱۷۰ |
منبع: گزارش نهایی زمان‌سنجی فرایند استعلام توقیف — شرکت سپرده‌گذاری مرکزی اوراق بهادار و تسویه وجوه (بدون نام اشخاص)
💡 نکتهٔ کلیدی این پروژه
در فعالیت «استخراج اطلاعات بخش عملیات»، Cycle Time واقعی فقط ۶٫۲ دقیقه بود، اما Lead Time به ۱۷۴ دقیقه رسید — یعنی بیش از ۸۰ دقیقه فراتر از SLA تعریف‌شده (۸۰ دقیقه). مجموع درگیری روزانهٔ هر نفر از کارگروه حقوقی برای این فرایند نیز فقط ۲۷٫۲ دقیقه از ۴۸۰ دقیقهٔ کاری بود — نشان میدهد ظرفیت آزاد کافی وجود داشت و تأخیر از جنس صف و توالی کار بود، نه کمبود نیرو.
کالبدشکافی مثال ۲۱۰ دقیقه‌ای
به مثال ابتدای مقاله برگردیم: انتظار قبل از شروع کار ۱۲۰ دقیقه، انجام واقعی کار ۳۰ دقیقه و انتظار برای تأیید ۶۰ دقیقه بود. بنابراین:
حالا نکته جالب مشخص می‌شود: از ۲۱۰ دقیقه‌ای که مشتری منتظر بوده، فقط ۳۰ دقیقه صرف انجام واقعی کار شده است؛ یعنی تقریباً:
این عدد می‌تواند نگاه مدیر به مسئله را کاملاً تغییر دهد.
آیا واقعاً باید کارشناس سریع‌تر کار کند؟
فرض کنید مدیر می‌خواهد زمان تحویل این خدمت را کاهش دهد. اولین راهکار ممکن است این باشد: «کارشناس باید سریع‌تر کار کند.» حالا دو سناریو را با هم مقایسه می‌کنیم:
با آموزش یا اتوماسیون، زمان پردازش را از ۳۰ دقیقه به ۲۰ دقیقه کاهش می‌دهیم (بهبود ۳۳٪ در Processing Time). زمان انتظارها (۱۲۰ و ۶۰ دقیقه) دست‌نخورده باقی می‌ماند.
۱۲۰ + ۲۰ + ۶۰ = ۲۰۰ دقیقه؛ یعنی با وجود ۳۳٪ بهبود در Processing Time، Lead Time مشتری فقط حدود ۵٪ کاهش پیدا کرده است.
کارشناس همچنان همان ۳۰ دقیقه کار میکند، اما با اصلاح جریان فرایند و حذف صف‌های غیرضروری، ۹۰ دقیقه از زمان انتظار حذف می‌شود.
Lead Time از ۲۱۰ به ۱۲۰ دقیقه می‌رسد؛ یعنی حدود ۴۳٪ بهبود در زمان تحویل، بدون اینکه از کارشناس حتی یک دقیقه سریع‌تر کار خواسته باشیم.
اینجاست که تفاوت میان بهینه‌سازی یک فعالیت و بهبود کل جریان فرایند مشخص می‌شود.
بهینه‌سازی محلی؛ یک دام مدیریتی
اگر فقط سرعت یک واحد یا فعالیت را افزایش دهیم، ممکن است صرفاً یک Local Optimization یا بهینه‌سازی محلی انجام داده باشیم. اما مشتری یک فعالیت را تجربه نمی‌کند؛ مشتری کل فرایند را تجربه میکند. بنابراین سؤال مدیر فرایند نباید فقط این باشد:
«انجام این فعالیت چقدر زمان می‌برد؟» — بلکه باید بپرسد: «درخواست از ابتدا تا انتها کجاها متوقف می‌شود و چرا؟»
در بسیاری از فرایندها، بزرگ‌ترین فرصت‌های بهبود نه داخل فعالیت‌ها، بلکه در فاصله میان فعالیت‌ها قرار دارند.
SLA چه تفاوتی با Lead Time و Cycle Time دارد؟
SLA یا Service Level Agreement مفهوم دیگری است و نباید با زمان واقعی انجام کار اشتباه گرفته شود. SLA سطح خدمت مورد انتظار یا تعهد سازمان برای ارائه خدمت است. مثلاً فرض کنید Lead Time واقعی برابر ۲۱۰ دقیقه و SLA حداکثر ۱۸۰ دقیقه باشد؛ در این حالت درخواست ۳۰ دقیقه دیرتر از سطح خدمت مورد انتظار تحویل شده است.
| شاخص | توضیح |
|---|---|
| Processing Time | واقعاً چقدر روی درخواست کار کردیم؟ |
| Cycle Time | عبور از چرخه موردنظر چقدر طول کشید؟ |
| Waiting Time | درخواست چقدر منتظر ماند؟ |
| Lead Time | مشتری از ابتدا تا انتها چقدر منتظر ماند؟ |
| SLA | حداکثر چقدر باید منتظر می‌ماند؟ |
این شاخص‌ها مکمل یکدیگرند، نه جایگزین یکدیگر.
WIP چیست و چرا روی زمان تحویل اثر می‌گذارد؟
WIP مخفف Work In Progress و به معنی تعداد کارهایی است که وارد جریان شده‌اند اما هنوز تکمیل نشده‌اند. تصور کنید یک تیم ظرفیت رسیدگی هم‌زمان به ۱۰ درخواست را دارد، اما ۵۰ درخواست را وارد جریان میکند. نتیجه معمولاً قابل پیش‌بینی است: صفها بزرگ‌تر می‌شوند، تمرکز کاهش پیدا میکند، جابه‌جایی بین کارها افزایش می‌یابد و درخواست‌ها مدت بیشتری در سیستم باقی می‌مانند.
Stop starting, start finishing.
به‌جای شروع کردن کارهای بیشتر، روی تمام کردن کارهای موجود تمرکز کنید. محدود کردن WIP یکی از مؤثرترین روش‌ها برای روان‌تر کردن جریان کار است.
Throughput یا توان عملیاتی چیست؟
Throughput نشان میدهد در یک بازه زمانی مشخص چند واحد کاری تکمیل می‌شود؛ مثلاً ۵۰ درخواست در روز یا ۲۰ پرونده در هفته.
Cycle Time
یک کار چقدر طول می‌کشد؟
Throughput
در یک بازه چند کار تکمیل می‌شود؟
WIP
چند کار هم‌اکنون در جریان است؟
قانون لیتل (Little's Law)
یکی از مهمترین روابط در مدیریت جریان، قانون لیتل است:
پیام مدیریتی این رابطه بسیار مهم است: اگر تعداد کارهای موجود در سیستم افزایش پیدا کند، اما توان عملیاتی متناسب با آن افزایش نیابد، زمان ماندن کارها در سیستم نیز بیشتر می‌شود. پس گاهی برای کاهش زمان تحویل نیازی به استخدام نیروی بیشتر نداریم؛ بلکه باید تعداد کارهای هم‌زمان و ورودی جریان را بهتر کنترل کنیم.
Takt Time چیست؟
Takt Time به سؤال متفاوتی پاسخ میدهد: «برای پاسخگویی به تقاضای مشتری، با چه آهنگی باید خروجی تولید کنیم؟»
فرض کنید در یک روز ۴۸۰ دقیقه زمان کاری در اختیار داریم و تقاضا ۶۰ درخواست در روز است: Takt Time = ۸ دقیقه؛ یعنی برای پاسخگویی به تقاضا، به‌طور متوسط باید هر ۸ دقیقه یک خروجی تکمیل شود.
پس Takt Time مدت‌زمان سپری‌شده یک درخواست نیست؛ بلکه ضرب‌آهنگ موردنیاز سیستم برای پاسخگویی به تقاضا را نشان میدهد.
برای کاهش Lead Time چه کار کنیم؟
اگر Lead Time یک فرایند زیاد است، قبل از افزایش نیرو یا فشار آوردن به کارکنان، این سؤالات را بررسی کنید:
- ۱
درخواست بیشتر از همه کجا منتظر می‌ماند؟
- ۲
بزرگ‌ترین صف در کدام نقطه فرایند تشکیل می‌شود؟
- ۳
کدام تأییدها واقعاً ضروری‌اند؟
- ۴
کجا پرونده بی‌دلیل بین واحدها دست‌به‌دست می‌شود؟
- ۵
کدام مرحله بیشترین برگشت و دوبارهکاری را ایجاد میکند؟
- ۶
آیا تعداد کارهای در جریان بیشتر از ظرفیت واقعی تیم است؟
- ۷
آیا می‌توان برخی تصمیم‌ها یا تأییدها را براساس قواعد کسب‌وکار خودکار کرد؟
- ۸
کدام Waiting Time را می‌توان بدون افزایش فشار کاری حذف کرد؟
پاسخ به این سؤالات معمولاً فرصت‌های بهبود بزرگ‌تری نسبت به چند دقیقه سریع‌تر انجام دادن یک فعالیت ایجاد میکند. شفافسازی مسئولیتها — مثلاً با تعریف یک ماتریکس مسئولیتها (RACI) برای هر فعالیت — و کوچکتر کردن Batchها معمولاً تأثیر زیادی روی کاهش دوبارهکاری و توقف‌های بی‌دلیل دارند. در پروژه‌های واقعی، بخش مهمی از این بهبودها با استقرار سیستم‌های BPM و اتوماسیون گردش کار به‌دست می‌آید؛ چراکه این سیستم‌ها امکان اندازهگیری دقیق Cycle Time، Waiting Time و پایش SLA را به‌صورت خودکار فراهم میکنند.
پروژهٔ سوم: تحول فرایندی «سمات» — از بهبود موضعی تا بازطراحی کامل ۸ فرایند
دو پروژهٔ کارسنجی بالا، ورودیِ یک برنامهٔ بزرگ‌تر بودند: پروژهٔ تحول فرایندی که در آن ۸ فرایند کلیدی — از توقیف سهام تا تسویهٔ فروش — بازطراحی، مکانیزه و پایش شدند. از ابتدای ۱۴۰۴ تا پایان مرداد ۱۴۰۵، مجموعاً ۴۶,۹۲۲ کیس در همین ۸ فرایند پردازش شد. نتایج زیر خروجی مستقیم و واقعی همین پروژه است — بدون هیچ نام سازمانی یا فردی محرمانه:
۵۴٪ کاهش میانگین Lead Time در ۴ فرایند اصلی، بدون افزایش نیروی انسانی
میانگین زمان انجام (Lead Time) در ۴ فرایند اصلی، از ۴٫۵۷ روز به ۲٫۱۲ روز رسید؛ آن‌هم در حالی که حجم عملیات ورودی در همین بازه، ۱۳٪ رشد کرده بود. این یعنی بهبود واقعاً از جنس «روان‌تر شدن جریان کار» بوده، نه صرفاً کاهش موقت بار کاری.
حجم عملیات به تفکیک هر ۸ فرایند
کاهش Lead Time به تفکیک زیرفرایند
در بخش تسویهٔ فروش، رهگیری مالی دقیق‌تر باعث شد حدود ۲ میلیارد تومان واریزی نامعلوم سال گذشته شناسایی شود؛ هدف سازوکار جدید، رساندن این رقم به صفر است. بخشی از این بازطراحی‌ها — از جمله مکانیزاسیون فرایند توثیق — با استقرار سیستم‌های BPM (پلتفرم Bizagi) در حال انجام است.
این بهبودها حاصل چهار اقدام هم‌زمان بودند: بازطراحی و یکپارچه‌سازی فرایندها، مکانیزاسیون و استانداردسازی گام‌های تکراری، حذف کار دستی و کنترل‌های زائد، و پایش SLA و مدیریت عملکرد به‌صورت مستمر — دقیقاً همان سؤالاتی که در بخش قبل مطرح شد.
داشبورد یک مدیر فرایند باید چه چیزی را نشان دهد؟
برای مدیریت حرفه‌ای عملکرد فرایند، نگاه کردن به یک عدد کافی نیست. بهتر است حداقل این شاخص‌ها کنار یکدیگر دیده شوند:
ترکیب این شاخص‌ها تصویر بسیار دقیق‌تری از عملکرد واقعی فرایند ارائه میکند.
دستاوردهای کسب‌وکاری کاهش Lead Time
کاهش زمان‌های انتظار و بهبود جریان فقط یک اقدام عملیاتی نیست؛ مستقیماً روی کسب‌وکار اثر می‌گذارد. نتایج آن می‌تواند شامل موارد زیر باشد:
قبل از سریع‌تر کار کردن، انتظار را کم کنید
تفاوت Lead Time و Cycle Time صرفاً تفاوت میان دو اصطلاح مدیریتی نیست؛ این تفاوت می‌تواند زاویه نگاه ما به مسئله عملکرد را تغییر دهد. ممکن است کارکنان یک سازمان بسیار سریع و کارآمد باشند، اما مشتری همچنان مدت زیادی برای دریافت نتیجه منتظر بماند. به همین دلیل:
- ✓
Processing Time را اندازه بگیرید تا بدانید واقعاً چقدر روی کار فعالیت می‌شود.
- ✓
Cycle Time را اندازه بگیرید تا سرعت عبور کار از چرخه را بشناسید.
- ✓
Waiting Time را اندازه بگیرید تا توقفها و اتلاف‌های جریان را پیدا کنید.
- ✓
Lead Time را اندازه بگیرید تا تجربه واقعی مشتری را ببینید.
- ✓
SLA را پایش کنید تا بدانید عملکرد واقعی با تعهد سازمان چقدر فاصله دارد.
نکته طلایی
قبل از اینکه تلاش کنیم افراد سریع‌تر کار کنند، کاری کنیم درخواست‌ها کمتر منتظر بمانند. چون در بسیاری از فرایندها، بزرگ‌ترین فرصت بهبود نه در خود فعالیت‌ها، بلکه در فاصله میان فعالیت‌ها پنهان شده است.
سؤالات متداول
+ تفاوت Lead Time و Cycle Time چیست؟
+ آیا Cycle Time همان Processing Time است؟
+ Waiting Time چیست؟
+ آیا Lead Time همیشه بیشتر از Cycle Time است؟
+ چگونه Lead Time را کاهش دهیم؟
+ تفاوت Takt Time با Cycle Time چیست؟
+ SLA چه تفاوتی با Lead Time دارد؟
+ مهمترین شاخص برای بهبود فرایند کدام است؟
می‌خواهید Lead Time واقعی فرایندهای سازمان‌تان را بسنجید؟
همان‌طور که در نمونه‌های واقعی این مقاله دیدید، شکاف میان Cycle Time و Lead Time را فقط با کارسنجی دقیق و بازطراحی جریان کار می‌توان پیدا و بسته کرد.
آشنایی با سیستم‌های BPM ←