فترة الإنجاز Cycle Time
إذا كان فريقك ينجز العمل باستمرار لكن موعد التسليم يظل غير متوقع، فأنت بحاجة إلى قياس تدفق العمل، لا عدد الساعات أو نسبة انشغال الأفراد فقط. تُعد فترة الإنجاز Cycle Time أحد أهم مقاييس التدفق في الإدارة الرشيقة وكانبان؛ لأنها توضح الزمن الفعلي الذي يستغرقه عنصر العمل منذ بدء تنفيذه حتى اكتماله.
يساعد هذا المقياس على اكتشاف الاختناقات، وتحسين القدرة على التنبؤ، وتقليل العمل الجاري، ورفع سرعة الاستجابة للعملاء. لكن استخدامه بطريقة صحيحة يحتاج تعريفًا موحدًا لنقطتي البداية والنهاية، وفهمًا للفرق بين الوقت المنقضي ووقت العمل النشط، وتحليلًا للتوزيع بدل الاكتفاء بمتوسط قد يخفي حالات التأخير.
ما هي فترة الإنجاز Cycle Time؟
هي مقدار الوقت المنقضي بين لحظة بدء العمل على عنصر محدد ولحظة اكتماله وفق تعريف سير العمل. ويعرّفها مرجع ProKanban لمقاييس التدفق بأنها الزمن المنقضي من بدء عنصر العمل حتى انتهائه.
يشمل الزمن المنقضي أيام العمل والانتظار والتعطل والمراجعة والاختبار، ما دامت تقع بين نقطتي البدء والانتهاء المحددتين. لذلك، لا تساوي Cycle Time عدد الساعات التي عمل فيها الموظف فعليًا. إذا استغرقت مهمة خمسة أيام تقويمية، وكان العمل النشط عليها ست ساعات فقط، ففترة الإنجاز تبقى خمسة أيام وفق تعريف التدفق.
قد يختلف التعريف بين الفرق. ففريق يبدأ القياس عند انتقال البطاقة إلى «قيد التنفيذ»، وينهيه عند «جاهز للإطلاق»، بينما ينهيه فريق آخر عند وصول العمل إلى المستخدم. كلاهما ممكن، لكن يجب توثيق التعريف واستخدامه باستمرار حتى تكون المقارنة صحيحة.
معادلة حساب Cycle Time
فترة الإنجاز = تاريخ ووقت الانتهاء − تاريخ ووقت البدء
إذا بدأ العمل صباح 5 مايو واكتمل صباح 9 مايو، فإن الزمن المنقضي أربعة أيام عند استخدام الفرق الزمني المباشر. وقد تستخدم بعض الأدوات عدًا شاملًا ليومي البداية والنهاية فتظهر خمسة أيام. الأهم اختيار قاعدة موحدة وتوثيقها، خصوصًا عند مقارنة البيانات بين منصات مختلفة.
يمكن القياس بالساعات للأعمال السريعة أو بالأيام للأسابيع والمشروعات المعرفية. كما يجب تحديد هل تُستخدم الأيام التقويمية أم أيام العمل. الأيام التقويمية تعكس انتظار العميل بصورة أوضح، بينما قد تفيد أيام العمل في بعض التحليلات الداخلية.
مثال على الحساب
| عنصر العمل | تاريخ البدء | تاريخ الانتهاء | Cycle Time |
|---|---|---|---|
| طلب تغيير كلمة المرور | 1 مايو | 3 مايو | يومان |
| إضافة تقرير للإدارة | 2 مايو | 10 مايو | 8 أيام |
| تحسين نموذج خدمة | 5 مايو | 9 مايو | 4 أيام |
| معالجة عيب تقني | 7 مايو | 9 مايو | يومان |
مجموع الفترات 16 يومًا لأربعة عناصر، فيكون المتوسط أربعة أيام. لكن المتوسط لا يخبرنا أن عنصر التقرير استغرق ضعف المدة تقريبًا مقارنة بباقي العناصر. لذلك، يجب مراجعة التوزيع والحالات الشاذة، لا الرقم المجمع وحده.
الفرق بين Cycle Time وLead Time
| المقياس | نقطة البداية | نقطة النهاية | ما الذي يوضحه؟ |
|---|---|---|---|
| Lead Time | طلب العميل أو تسجيل الحاجة | التسليم أو الإكمال | مدة انتظار العميل الكاملة |
| Cycle Time | بدء التنفيذ الفعلي | اكتمال العمل | سرعة تدفق العمل بعد البدء |
إذا قُدم الطلب في 1 مايو، وبدأ العمل عليه في 6 مايو، واكتمل في 10 مايو، فإن Lead Time يساوي تسعة أيام تقريبًا، بينما Cycle Time تساوي أربعة أيام. الفرق بينهما هو وقت الانتظار قبل البدء، وهو مهم لأنه يؤثر مباشرة في تجربة العميل.
علاقته بمقاييس التدفق الأخرى
| المقياس | التعريف | الاستخدام |
|---|---|---|
| WIP | عدد العناصر التي بدأت ولم تكتمل | معرفة حجم العمل الجاري |
| Throughput | عدد العناصر المكتملة خلال وحدة زمنية | قياس معدل الإنجاز |
| Work Item Age | عمر العنصر الجاري منذ بدئه حتى الآن | كشف العناصر المعرضة للتأخر |
| Cycle Time | الزمن المنقضي لعنصر مكتمل | تحليل الأداء التاريخي والتنبؤ |
ترتبط هذه المقاييس ببعضها. عندما يبدأ الفريق عناصر أكثر من قدرته، يرتفع WIP، وتزداد فترات الانتظار والتبديل بين المهام، وغالبًا ترتفع Cycle Time. لذلك، يكون تقليل العمل الجاري من أقوى وسائل تحسين التدفق دون مطالبة الأفراد بالعمل لساعات أطول.
أهمية قياس فترة الإنجاز
- التنبؤ بالتسليم: استخدام البيانات التاريخية لتقدير المدة المحتملة لعناصر مشابهة.
- كشف الاختناقات: معرفة المراحل التي تتراكم فيها فترات الانتظار.
- تحسين تجربة العميل: تقليل الوقت الذي يستغرقه تحويل الحاجة إلى نتيجة.
- تقييم التحسينات: مقارنة الأداء قبل تعديل العملية وبعده.
- إدارة التوقعات: إعطاء نطاقات احتمالية بدل مواعيد مبنية على الحدس.
- دعم التحسين المستمر: توجيه النقاش إلى النظام بدل لوم الأفراد.
فترة قصيرة ليست دائمًا دليل جودة؛ فقد يسرع الفريق على حساب الاختبار أو يعمد إلى تقسيم العمل بصورة شكلية. لذلك، يجب قراءة المقياس بجانب الجودة ورضا العميل وThroughput. الهدف تدفق قيمة مستقرة، لا تحطيم رقم قياسي في تحريك البطاقات.
طريقة قياس Cycle Time عمليًا
- حدد وحدة العمل: طلب خدمة أو قصة مستخدم أو عيب أو مهمة، وتجنب خلط أحجام وأنواع شديدة الاختلاف.
- عرّف نقطة البدء: مثل انتقال البطاقة إلى In Progress، لا مجرد تعيينها لموظف.
- عرّف نقطة الانتهاء: مثل تحقيق Definition of Done أو وصول العمل إلى Ready for Release.
- سجل الوقت تلقائيًا: استخدم بيانات أداة العمل لتقليل أخطاء الإدخال اليدوي.
- صنف البيانات: افصل العيوب عن الخصائص والطلبات العاجلة عن العادية.
- حلل التوزيع: راجع المتوسط والوسيط والمئينات والحالات الشاذة.
- نفذ تحسينًا واحدًا: مثل تقليل WIP أو تقديم المراجعة الأمنية، ثم راقب الأثر.
يمكن تمثيل سير العمل بلوحة كانبان أو منهج الإدارة الرشيقة المناسب، لكن الأداة لا تعوض تعريفًا واضحًا للعمل. إذا حرك الأعضاء البطاقات في أوقات مختلفة عن الواقع، فستكون البيانات جميلة وغير مفيدة.
لماذا لا يكفي المتوسط؟
يتأثر المتوسط بالعناصر شديدة التأخر. إذا كانت الفترات 2 و3 و3 و4 و18 يومًا، فالمتوسط 6 أيام، رغم أن أربعة من خمسة عناصر اكتملت خلال أربعة أيام أو أقل. الوسيط هنا 3 أيام، ويعبر عن الحالة النموذجية بصورة أفضل.
أما المئين 85 فيجيب تقريبًا: خلال كم يوم اكتمل 85% من العناصر السابقة؟ ويمكن استخدامه لصياغة توقع خدمة مثل: «لدينا احتمال 85% لإكمال هذا النوع خلال عشرة أيام أو أقل». هذا توقع احتمالي مبني على التاريخ، وليس وعدًا مضمونًا.
بناء توقع مستوى الخدمة SLE
توقع مستوى الخدمة Service Level Expectation هو تقدير احتمالي للمدة التي يُتوقع أن يستغرقها عنصر العمل من البدء حتى الانتهاء. يمكن صياغته مثل: «نتوقع إكمال 85% من طلبات الخدمة القياسية خلال ثمانية أيام أو أقل». ويُبنى على بيانات Cycle Time التاريخية لعناصر متشابهة، لا على موعد يختاره المدير دون أساس.
يفيد SLE في إدارة توقعات أصحاب المصلحة ومراقبة العناصر الجارية. فإذا تجاوز عمر عنصر العمل الحد المتوقع قبل اكتماله، يستطيع الفريق مناقشة سبب التعطل مبكرًا. لكنه لا يمثل اتفاقية مستوى خدمة تعاقدية بالضرورة، ولا يضمن إكمال كل عنصر داخل المدة؛ فهو توقع يعتمد على الاحتمال وجودة البيانات.
جودة البيانات قبل اتخاذ القرار
قد تعطي أدوات العمل أرقامًا مضللة إذا لم يُحدّث أعضاء الفريق حالة البطاقات وقت حدوث التغيير، أو أعادوا فتح العناصر دون سياسة واضحة، أو جمعوا مهامًا ضخمة وصغيرة في التحليل نفسه. لذلك، راجع تعريفات الحالات، وعالج البيانات الناقصة، وحدد طريقة التعامل مع العناصر الملغاة والمعاد فتحها قبل استخراج المؤشرات.
ومن الضروري التأكيد أن Cycle Time تقيس الوقت المنقضي؛ أي إنها تشمل الانتظار والتعطل والاختبار إذا حدثت بين نقطة البدء ونقطة الانتهاء. استبعاد هذه الفترات يحول المقياس إلى وقت عمل نشط، وهو مقياس مختلف لا يعكس سرعة تدفق القيمة عبر النظام.
تحليل Cycle Time Scatterplot
يعرض المخطط المبعثر كل عنصر مكتمل كنقطة؛ يمثل المحور الأفقي تاريخ الإكمال، والعمودي مدة الإنجاز. تظهر من خلاله الاتجاهات والحالات الشاذة والتغير بمرور الوقت. فإذا ارتفعت النقاط تدريجيًا، فقد يشير ذلك إلى اختناق أو زيادة WIP أو تغير في حجم العمل.
يمكن إضافة خطوط المئينات إلى المخطط لتكوين نطاقات توقع. كما يفيد تلوين النقاط حسب نوع العمل، لأن مقارنة عيب صغير بمبادرة كبيرة قد تنتج استنتاجات مضللة.
كيف نقلل فترة الإنجاز؟
- تقليل WIP: إنهاء العمل الجاري قبل بدء عناصر جديدة.
- تقسيم العناصر: تحويل الأعمال الكبيرة إلى شرائح قيمة أصغر قابلة للإكمال.
- إزالة الاختناقات: دعم المرحلة الأبطأ بدل تحسين مراحل لا تقيد التدفق.
- تقليل التسليمات بين الأشخاص: بناء فرق متعددة المهارات وتعزيز التعاون.
- تقديم الجودة: إجراء الاختبار والمراجعة مبكرًا لتقليل إعادة العمل.
- أتمتة الخطوات المتكررة: مثل الاختبارات والنشر والإشعارات عند جدواها.
- تحديد سياسات صريحة: توضيح شروط دخول كل مرحلة والخروج منها.
مثال عملي على التحسين
لاحظ فريق تطوير خدمات داخلية أن الوسيط أربعة أيام، لكن المئين 85 بلغ 18 يومًا. أظهر المخطط أن العناصر تتوقف طويلًا في المراجعة القانونية. بدل مطالبة المطورين بالسرعة، اتفق الفريق مع المستشار القانوني على معايير مسبقة ووقت مراجعة ثابت، وقسم الطلبات إلى عادية واستثنائية.
بعد شهرين انخفض المئين 85 إلى عشرة أيام، بينما لم يتغير وقت البرمجة كثيرًا. التحسن جاء من تقليل الانتظار، وهو ما لم يكن سيظهر لو قاس الفريق ساعات العمل النشط فقط.
أخطاء شائعة عند استخدام المقياس
- كتابة المصطلح Cycle Team بدل Cycle Time.
- استبعاد الانتظار والاختبار رغم وقوعهما داخل سير العمل المحدد.
- تغيير نقطتي البداية والنهاية ثم مقارنة النتائج القديمة بالجديدة.
- خلط أنواع أعمال مختلفة في مجموعة واحدة.
- استخدام المتوسط وحده وتجاهل التوزيع والمئينات.
- تحويل المقياس إلى أداة لتقييم الموظفين أو مقارنتهم.
- تقليل الزمن على حساب الجودة والقيمة.
قائمة تحقق سريعة
- هل نقطتا البدء والانتهاء واضحتان ومتفق عليهما؟
- هل نقيس الوقت المنقضي لا ساعات العمل فقط؟
- هل أنواع العناصر متشابهة وقابلة للمقارنة؟
- هل نراجع الوسيط والمئين 85 والحالات الشاذة؟
- هل نقرأ Cycle Time مع WIP وThroughput والجودة؟
- هل نستخدم البيانات لتحسين النظام لا لوم الأفراد؟
أسئلة شائعة
هل يدخل وقت الاختبار ضمن Cycle Time؟
نعم إذا كان الاختبار يقع بين نقطتي البدء والانتهاء في تعريف سير العمل. وإذا كان «مكتمل» يتطلب اجتياز الاختبار، فلا يجوز إيقاف القياس قبله.
هل Cycle Time تقيس إنتاجية الفرد؟
لا. هي مقياس لتدفق عنصر العمل عبر النظام، وتشمل وقتًا لدى عدة أشخاص ومراحل. استخدامها لتقييم فرد يشجع سلوكيات تضر التعاون وجودة البيانات.
ما الفترة المثالية للإنجاز؟
لا توجد قيمة عالمية؛ تعتمد على نوع العمل وحجمه والجودة المطلوبة. الأفضل مقارنة الفريق بنفسه وتحسين الاستقرار والقيمة بدل تقليد أرقام فريق آخر.
الخلاصة
توضح فترة الإنجاز Cycle Time الزمن المنقضي من بدء عنصر العمل حتى اكتماله، بما في ذلك الانتظار والتعطل والمراجعة والاختبار داخل حدود سير العمل. وهي تساعد الفرق على فهم التدفق والتنبؤ بالتسليم واكتشاف الاختناقات.
ابدأ بتعريف واضح لنقطتي البداية والنهاية، ثم اجمع بيانات العناصر المتشابهة وحلل الوسيط والمئينات مع WIP وThroughput والجودة. لا تسأل فقط: كم عمل الفريق؟ بل اسأل: أين بقي العمل منتظرًا، ولماذا؟ غالبًا ستجد فرصة التحسين هناك.
رأي واحد حول “فترة الإنجاز Cycle Time”