لماذا يغيّر MS Project وPrimavera التواريخ من تلقاء نفسه؟

عندما يفتح مدير المشروع ملف الجدول فيجد أن MS Project أو Primavera غيّر تاريخ بداية مهمة، أو حرّك نهاية نشاط، أو بدّل قيمة الـ Float دون سبب واضح، يكون الإغراء الأول هو تعديل التاريخ يدوياً. لكن هذا غالباً يعالج العرض لا السبب.

الهدف من هذا الدليل هو مساعدتك على تشخيص مشاكل الجدولة في MS Project وPrimavera بمنطق مهني: تفهم كيف يفكر محرك الجدولة، وتفحص الإعدادات والعلاقات والقيود والتقاويم قبل أن تتخذ قراراً قد يفسد المسار الحرج أو يخفي مشكلة حقيقية في الخطة.

جدول المحتويات

• لماذا تبدو التواريخ وكأنها تتغير من تلقاء نفسها؟
• الخطوة الأولى في تشخيص مشاكل الجدولة في MS Project وPrimavera: افحص نوع الجدولة
• افحص التقويم قبل العلاقات: كثير من المشاكل تبدأ من أيام العمل
• تحقق من علاقات الاعتماد: ليست كل الأسهم تعني ما تتخيله
• افهم القيود: عندما تقول للبرنامج «لا تتحرك»
• لا تحلل الـ Float قبل فهم المسار الحرج وطريقة الحساب
• راجع التقدم الفعلي وStatus Date: التاريخ الماضي ليس مثل المستقبل
• تحقق من تسوية الموارد: قد تكون الموارد هي التي تحرك التواريخ
• لا تثق في طريقة العرض قبل فحص الفلاتر وخط الأساس
• قائمة فحص سريعة قبل تعديل أي تاريخ يدوياً
• أخطاء شائعة تجعل الجدول غير قابل للتشخيص
• خلاصة: عالج منطق الجدولة لا أعراضه

لماذا تبدو التواريخ وكأنها تتغير من تلقاء نفسها؟

برامج الجدولة لا تختار التواريخ عشوائياً. هي تعيد حسابها بناءً على مجموعة قواعد: تاريخ بداية المشروع، علاقات الاعتماد، مدد الأنشطة، التقاويم، القيود، التقدم الفعلي، تاريخ الحالة، وتوفر الموارد إذا كانت التسوية مفعّلة.

لذلك، عندما يتغير تاريخ ما، فالسؤال الصحيح ليس: «لماذا خرب البرنامج الجدول؟» بل: «أي قاعدة دفعت محرك الجدولة إلى هذه النتيجة؟». هذا التحول في التفكير هو الفرق بين مستخدم يطارد التواريخ ومخطط مشاريع يفهم النموذج الزمني للمشروع.

الخطوة الأولى في تشخيص مشاكل الجدولة في MS Project وPrimavera: افحص نوع الجدولة

قبل تحليل العلاقات والتقاويم، تأكد من أن المهمة أو النشاط يخضع فعلاً لمحرك الجدولة. في MS Project توجد مهام يدوية الجدولة وأخرى تلقائية الجدولة. المهمة اليدوية قد تحتفظ بتاريخ كتبه المستخدم حتى لو تعارض مع المنطق العام، بينما المهمة التلقائية تتحرك حسب الحسابات.

في Primavera P6، المنطق أكثر صرامة عادةً، لكن إعدادات المشروع وخيارات الحساب قد تؤثر في طريقة التعامل مع الأنشطة المفتوحة أو العلاقات أو الموارد. لذلك لا تبدأ بتغيير تاريخ النشاط، بل اسأل:

• هل المهمة في MS Project مجدولة يدوياً أم تلقائياً؟
• هل تم حساب الجدول بعد آخر تعديل؟
• هل توجد إعدادات تمنع تحديث تواريخ معينة أو تؤخر إعادة الحساب؟
• هل تنظر إلى التاريخ المخطط، أم التاريخ الفعلي، أم تاريخ البدء/النهاية الحالي؟

في بيئات العمل الاحترافية، يفضّل توحيد سياسة الجدولة: المهام التنفيذية الرئيسية تكون تلقائية الجدولة، بينما تستخدم المهام اليدوية فقط في المسودات أو المعلومات المؤقتة.

افحص التقويم قبل العلاقات: كثير من المشاكل تبدأ من أيام العمل

التقويم هو العدسة التي يرى بها البرنامج الزمن. إذا كان التقويم لا يسمح بالعمل يوم الجمعة، فلن تبدأ المهمة يوم الجمعة مهما بدت العلاقة منطقية. وإذا كان نشاط في Primavera يستخدم تقويم نشاط مختلفاً عن تقويم المشروع، فقد تحصل على تاريخ لا يتوقعه مدير المشروع.

ما الذي يجب فحصه في التقويم؟

• تقويم المشروع العام: ما أيام العمل الرسمية؟ وما ساعات العمل اليومية؟
• تقويم المهمة أو النشاط: هل تم تعيين تقويم خاص يختلف عن تقويم المشروع؟
• تقويم المورد في MS Project: هل المورد غير متاح في أيام معينة؟
• العطل والاستثناءات: هل توجد إجازات أو أيام توقف أُدخلت سابقاً؟
• وحدة المدة: هل «يومان» تعني يومي عمل أم 16 ساعة أم شيئاً آخر؟

مثال عملي: إذا كان لديك نشاط مدته 5 أيام يبدأ يوم الخميس، وتقويم المشروع يستبعد الجمعة والسبت، فمن الطبيعي أن يظهر تاريخ النهاية في الأسبوع التالي. هذا ليس خطأ في Gantt، بل نتيجة مباشرة للتقويم.

تحقق من علاقات الاعتماد: ليست كل الأسهم تعني ما تتخيله

أكثر أسباب تغيّر التواريخ شيوعاً هو سوء فهم العلاقات. في أدوات الجدولة، السهم ليس مجرد «يأتي بعده». له نوع محدد وتأخير أو تقديم قد يغير كل الخطة.

عند تشخيص علاقة لا تعمل كما تتوقع، لا تكتفِ برؤية السهم في مخطط Gantt. افتح تفاصيل العلاقة وافحص النوع والـ Lag. تأخير +3 أيام أو تقديم -2 أيام قد يكون السبب الحقيقي وراء التاريخ الغريب.

قاعدة مهنية مهمة

لا تستخدم القيود لإجبار تاريخ كان يمكن تمثيله بعلاقة منطقية. العلاقة تصف تسلسل العمل، أما القيد فيفرض تاريخاً. الخلط بينهما يجعل الجدول هشاً ويصعب تحليله.

افهم القيود: عندما تقول للبرنامج «لا تتحرك»

القيود مثل Must Start On أو Start No Earlier Than أو Finish No Later Than تضيف قواعد فوق منطق الشبكة. أحياناً تكون ضرورية، مثل موعد تسليم تعاقدي أو إغلاق موقع عمل. لكنها إذا استخدمت بكثرة، تتحول إلى مصدر رئيسي لتواريخ غير مفهومة.

في MS Project قد ترى أيقونة قيد بجانب المهمة. في Primavera يمكن مراجعة قيود النشاط من تبويب الحالة أو التفاصيل. عند وجود قيد، اسأل:

• هل القيد يعكس التزاماً حقيقياً أم مجرد تاريخ كتبه شخص لتجميل الجدول؟
• هل نوع القيد مرن أم صارم؟
• هل يتعارض القيد مع العلاقات السابقة واللاحقة؟
• هل يخلق Float غير منطقي أو يخفي التأخير الحقيقي؟

مثال: إذا وضعت قيداً بأن نشاطاً يجب أن يبدأ في 10 يونيو، بينما يسبقه نشاط لا ينتهي قبل 15 يونيو، سيحاول البرنامج إظهار التعارض بطريقة ما: تحذير، Float سالب، أو تاريخ يبدو غير منطقي. المشكلة هنا ليست في الحساب، بل في تناقض التعليمات.

لا تحلل الـ Float قبل فهم المسار الحرج وطريقة الحساب

الـ Float ليس رقماً ثابتاً؛ إنه نتيجة لحساب الشبكة بالكامل. أي تعديل في علاقة، تقويم، قيد، مدة، أو تاريخ حالة قد يغيره. لذلك من الخطأ اعتبار تغيّر الـ Float مشكلة مستقلة قبل فحص المدخلات.

في Primavera خصوصاً، قد تختلف قراءة Total Float حسب إعدادات الجدولة، طريقة حساب المسار الحرج، والقيود المفروضة. وفي MS Project قد يتأثر المسار الحرج بموعد نهاية المشروع أو القيود أو المهام غير المكتملة.

كيف تتعامل مع Float متغير؟

1. حدد هل تقيس Total Float أم Free Float.
2. راجع آخر نشاط في المسار: هل له قيد نهاية؟
3. افحص الأنشطة ذات Float سالب؛ غالباً تشير إلى تعارض مع موعد إلزامي.
4. قارن الحساب قبل وبعد آخر تحديث لتعرف ما الذي تغير.
5. لا تعالج Float بتعديل التواريخ؛ عالج العلاقات أو القيود أو الفرضيات.

راجع التقدم الفعلي وStatus Date: التاريخ الماضي ليس مثل المستقبل

بعد تحديث المشروع، تظهر مشكلات كثيرة لأن المستخدمين يخلطون بين المخطط والفعلي. إذا أدخلت Actual Start لمهمة، فلن يتعامل معها البرنامج كافتراض قابل للتحريك بسهولة. وإذا بقي جزء غير منفذ من نشاط قبل تاريخ الحالة، فقد تظهر انزياحات أو تحذيرات.

Status Date أو تاريخ الحالة هو الخط الذي يقول للجدول: «نحن نقيم المشروع حتى هذا اليوم». أي عمل غير مكتمل قبل هذا التاريخ يحتاج تفسيراً: هل تأخر؟ هل يجب إعادة جدولته؟ هل تم تحديث النسبة فقط دون إدخال تواريخ فعلية؟

أسئلة تشخيصية عند التحديث

• هل تم إدخال Actual Start وActual Finish بدقة؟
• هل النسبة المئوية للتقدم تعكس العمل الحقيقي أم تقديراً عاماً؟
• هل توجد أنشطة كان يفترض أن تبدأ قبل تاريخ الحالة ولم تبدأ؟
• هل استخدمت أمر إعادة جدولة العمل غير المكتمل بعد تاريخ الحالة؟
• هل تم تحديث العلاقات بعد تغير واقع التنفيذ؟

من الخبرة العملية، كثير من الجداول تنهار ليس بسبب التخطيط الأولي، بل بسبب تحديثات غير منضبطة: نسب إنجاز بلا تواريخ، Actuals غير متسقة، أو Status Date غير محدث.

تحقق من تسوية الموارد: قد تكون الموارد هي التي تحرك التواريخ

إذا كانت تسوية الموارد مفعّلة، فقد يؤخر البرنامج بعض المهام لأن المورد نفسه مخصص لأكثر من عمل في الوقت ذاته. هنا لا تكون العلاقات أو القيود هي السبب المباشر، بل قيود القدرة الاستيعابية.

في MS Project، افحص ما إذا كان Resource Leveling تلقائياً أم يدوياً، وهل يسمح بتقسيم المهام أو تأخيرها ضمن الـ Slack. في Primavera، راجع إعدادات Resource Leveling وتأثيرها على تواريخ الأنشطة مقارنة بحساب الجدول العادي.

قاعدة عملية: عند ظهور تاريخ غير متوقع، احسب الجدول مرة دون تسوية موارد، ثم قارنه بالنسخة المسوّاة. إذا اختفى الانزياح، فالسبب غالباً تخصيص الموارد وليس منطق العلاقات.

لا تثق في طريقة العرض قبل فحص الفلاتر وخط الأساس

أحياناً لا تكون المشكلة في الجدول أصلاً، بل في العرض. قد لا تظهر مهمة في Tracking Gantt بسبب فلتر، مجموعة، نطاق تاريخ، مستوى طي، أو اختلاف بين الخطة الحالية وخط الأساس.

قبل استنتاج أن النشاط اختفى أو أن المخطط لا يعمل، افحص:

• هل يوجد فلتر نشط يخفي المهام المكتملة أو غير الحرجة؟
• هل تم طي ملخصات WBS أو Summary Tasks؟
• هل تنظر إلى Baseline أم Current Schedule؟
• هل مقياس الزمن في Gantt يغطي الفترة المطلوبة؟
• هل تم تطبيق Grouping يغير ترتيب الأنشطة؟

في المراجعات التنفيذية، من الأفضل حفظ طريقة عرض قياسية للفريق حتى لا يختلف تفسير الجدول من شخص لآخر بسبب إعدادات العرض.

قائمة فحص سريعة قبل تعديل أي تاريخ يدوياً

استخدم هذه القائمة كلما واجهت تاريخاً غير متوقع. الهدف هو تحديد مصدر القرار الزمني داخل البرنامج بدلاً من كسر النموذج بتعديل يدوي.

1. حدد نوع التاريخ: هل هو Planned أو Actual أو Baseline أو Early/Start Finish؟
2. افحص نوع الجدولة: يدوي أم تلقائي؟ وهل تمت إعادة الحساب؟
3. راجع التقويم: تقويم المشروع، النشاط، المورد، والعطل.
4. حلل العلاقات: النوع، الاتجاه، Lag، والأنشطة السابقة واللاحقة.
5. ابحث عن القيود: خاصة القيود الصارمة أو مواعيد النهاية الإلزامية.
6. راجع Actuals: هل توجد تواريخ فعلية تقيد الحركة؟
7. افحص Status Date: هل يعكس تاريخ التحديث الحقيقي؟
8. اختبر تسوية الموارد: قارن الجدول قبل وبعد Leveling.
9. راجع طريقة العرض: الفلاتر، التجميع، نطاق الزمن، وخط الأساس.
10. وثّق السبب: لا تعدّل التاريخ قبل أن تعرف القاعدة التي حرّكته.

أخطاء شائعة تجعل الجدول غير قابل للتشخيص

هناك ممارسات تبدو سريعة لكنها تجعل الجدول ضعيفاً أمام التحليل. أبرزها إدخال تواريخ يدوية لكل نشاط، استخدام قيود كثيرة بدلاً من العلاقات، ترك أنشطة بلا سوابق أو لواحق، وتحديث النسبة المئوية فقط دون تواريخ فعلية.

كذلك، من الأخطاء الشائعة بناء جدول بتقويم غير واضح، أو استخدام Lag كبير للتعبير عن عمل مستقل كان يجب أن يكون نشاطاً منفصلاً، أو تجاهل خط الأساس ثم محاولة قياس الانحرافات لاحقاً. هذه الممارسات لا تمنع البرنامج من الحساب، لكنها تجعل نتائجه صعبة التفسير.

خلاصة: عالج منطق الجدولة لا أعراضه

إذا غيّر MS Project أو Primavera التواريخ، فغالباً هو يستجيب لمنطق موجود في الملف: علاقة، تقويم، قيد، Actual، Status Date، أو تسوية موارد. لذلك يبدأ تشخيص مشاكل الجدولة في MS Project وPrimavera من فهم القاعدة التي تحكم التاريخ، لا من تعديل التاريخ نفسه.

أفضل ممارسة هي بناء جدول يمكن تفسيره: علاقات واضحة، قيود قليلة ومبررة، تقاويم مضبوطة، تحديثات فعلية منضبطة، وطريقة عرض موحدة. عندها يصبح تغيّر التواريخ إشارة مفيدة لفهم المشروع، لا مفاجأة مزعجة في مخطط Gantt.