العميل يعمل على MS Project وأنت على Primavera P6. أو العكس. لا بدّ أن يحوّل أحدٌ الجدول الزمني، وفي كل مرة يُنجَز ذلك "بما هو متاح"، يضيع شيء ما: تقويم، أو عشرون lag، أو المسار الحرج بأكمله. يشرح هذا الدليل ما الذي يختلف بين نموذجَي البيانات، وما الطريقة الصحيحة للتحويل، وكيفية التحقق من النتيجة في عشر دقائق.
لماذا ليس مجرّد "حفظ باسم"
يمثّل Primavera P6 وMS Project الجدول الزمني نفسه ببُنى مختلفة. التحويل لا ينسخ ملفًا: بل يترجم نموذجًا إلى آخر، وكل ترجمة فيها فاقد إن لم تُضبَط. هذه هي النقاط التي ينكسر فيها أكثر:
| المفهوم | Primavera P6 | MS Project | المخاطرة عند التحويل |
|---|---|---|---|
| التقويمات | عامّة، وللمشروع، وللموارد؛ ساعات/اليوم محدّدة بحسب التقويم | تقويم أساسي + تقويمات للمهام؛ ساعات/اليوم في خيارات المشروع | عالية: يُعاد تفسير المُدَد بالساعات إذا لم تتطابق ساعات/اليوم |
| WBS | بنية مستقلّة عن الأنشطة | مهام تلخيصية متداخلة | متوسطة: مستويات فارغة أو رموز WBS مفقودة |
| العلاقات والـ lags | يُحسَب الـ lag على تقويم النشاط اللاحق أو السابق (قابل للضبط) | الـ lag على تقويم المهمة اللاحقة | متوسطة: انزياحات من 1 إلى 3 أيام في الـ lags الطويلة |
| القيود | Start On، Finish On، Mandatory، As Late As Possible… | أنواع أقل؛ Mandatory غير موجود | متوسطة: تتحوّل القيود الصارمة إلى مرنة أو العكس |
| أنشطة LOE والتلخيصية | أنواع أنشطة خاصة به | غير موجودة | عالية: قد يصبح نشاط LOE المحوَّل إلى مهمة عادية حرجًا |
| نسبة الإنجاز | حسب المدة، أو فعلية، أو حسب الوحدات (قابلة للاختيار) | % completed (المدة) و% work completed | متوسطة: يضيع الإنجاز الفعلي إن لم يُربَط بحقل مخصّص |
| الرموز وUDF | رموز الأنشطة والحقول المعرَّفة من المستخدم | حقول مخصّصة Text1…Text30، إلخ. | منخفضة إذا رُبطت؛ عالية إذا أُهملت |
| خطوط الأساس | عدّة خطوط، تُحفَظ كمشاريع منفصلة | حتى 11 داخل الملف | متوسطة: التصدير دون baseline يترك العميل بلا مرجع |
السبب الأول لاختلاف التواريخ بعد التحويل هو التقويم: ملف P6 بـ 10 ساعات/اليوم و6 أيام/الأسبوع يُفتَح في MS Project مضبوط على 8 ساعات/اليوم و5 أيام/الأسبوع يُطيل المشروع أسابيع كاملة دون المساس بمدة واحدة.
الطرق الثلاث للتحويل
- التصدير من P6 إلى XML الخاص بـ MS Project. يقوم P6 Professional بذلك من File → Export → Microsoft Project XML. يصلح للشبكات البسيطة، لكنه معروف بفقدان التقويمات المتعدّدة ورموز الأنشطة، وبتوليد مهام تلخيصية غريبة عندما تحتوي WBS على مستويات بلا أنشطة.
- التحويل بأداة متخصّصة. El Conversor من TecnoAdmin يقرأ ملف .xer مباشرةً ويولّد ملف .mpp أو .xml جاهزًا للفتح، مع الحفاظ على WBS والعلاقات والـ lags والتقويمات والقيود والرموز كحقول مخصّصة. كما يقوم بالطريق العكسي (.mpp ← .xer) ويصدّر نسخ Candy الاحتياطية إلى Excel. وهو مجاني ولا يتطلّب تثبيت أي شيء.
- إعادة البناء يدويًا. لا معنى لذلك إلا للجداول الزمنية الصغيرة أو عندما تتطلّب الوجهة بنية مختلفة جدًا. لأكثر من 200 نشاط، تتجاوز مخاطرة الخطأ البشري أي فائدة.
اطّلع على جميع أدواتنا للجداول الزمنية، ومنها المحوّل ومدقّق DCMA، في منتجات TecnoAdmin.
خطوة بخطوة: من XER إلى MPP باستخدام El Conversor
نظّف الجدول الزمني في P6
شغّل Schedule (F9) بتاريخ البيانات الصحيح، واحذف الأنشطة والرموز اليتيمة، وتحقّق من عدم وجود فائض سالب غير مبرَّر. ما هو معطوب في P6 سيصل معطوبًا إلى الوجهة.
صدّر ملف .xer
File → Export → Primavera PM (XER). صدّر المشروع فقط، دون موارد عامّة غير ضرورية. إذا احتاج العميل خط الأساس، فصدّر أيضًا مشروع الـ baseline أو احتفظ بملف .xer الخاص به في متناولك.
ارفع الملف واختر الصيغة
في El Conversor اسحب ملف .xer، وراجع المعاينة (عدد الأنشطة، وتواريخ البداية والنهاية، والتقويمات المكتشَفة) واختر .mpp أو .xml الخاص بـ MS Project. إذا كان لديك خط الأساس، فحمّله في الخطوة نفسها.
افتح في MS Project وأعِد الحساب
عند الفتح، اضغط F9. تأكّد في Project → Project Information من أن تاريخ الحالة يطابق تاريخ البيانات في P6 وأن جميع المهام في وضع Auto Scheduled.
تحقّق
لا تسلّم قبل المرور بقائمة التحقق في القسم التالي. عشر دقائق الآن توفّر أسبوع النقاش الذي يأتي حين يكتشف العميل الفرق.
التحقق في 10 دقائق
قارن الملف الأصلي والمحوَّل في هذه النقاط الثماني. لكل اختلاف سبب محدّد، وهو في الغالب موجود في جدول المخاطر أعلاه.
| التحقق | يجب أن يتحقّق | إن لم يتطابق، راجع |
|---|---|---|
| عدد الأنشطة | متساوٍ (دون احتساب التلخيصية) | أنشطة LOE أو معالم مُستبعَدة |
| عدد العلاقات | متساوٍ | علاقات مكرّرة أو مرتبطة بمهام تلخيصية |
| تاريخ نهاية المشروع | التاريخ نفسه، دون تسامح | التقويم (ساعات/اليوم، أيام/الأسبوع) |
| المدة الإجمالية بالأيام | متساوية | مُدَد بالساعات أُسيء تفسيرها |
| المسار الحرج | الأنشطة الحرجة العشرة الأولى نفسها | قيود متدهورة، أنشطة LOE محوَّلة إلى مهام |
| المعالم التعاقدية | التواريخ نفسها | قيود مفقودة |
| الإنجاز الإجمالي حتى التاريخ | نفس % الفعلي أو حسب المدة | نوع نسبة غير مربوط |
| تقييم DCMA | النتائج نفسها في النقاط الـ 14 | Lags، أنشطة معلّقة، تواريخ غير صالحة جديدة |
حيلة سريعة: مرّر الملف الأصلي والمحوَّل عبر Centinela DCMA. إذا أعطت النقاط الـ 14 النتيجة نفسها في الملفين، فقد نجا المنطق من التحويل. وإذا تغيّرت النقطة 1 (المنطق) أو 3 (الـ lags)، فأنت تعرف أين تنظر.
أخطاء شائعة وكيفية تصحيحها
- ينتهي المشروع بعد أسابيع. السبب في الغالب هو التقويم. في MS Project اضبط Options → Schedule → Hours per day / Days per week والتقويم الأساسي على النمط نفسه الذي كان في P6.
- تظهر مهام حرجة لم تكن كذلك. أنشطة LOE محوَّلة إلى مهام عادية. حدّدها وعلّمها كغير نشطة أو حوّلها إلى مهام تلخيصية يدوية.
- انزاحت الـ lags يومًا أو يومين. اختلاف في التقويم المستخدم للـ lag. راجع في P6 خيار Calendar for scheduling relationship lag واضبط العلاقات المتأثّرة.
- تواريخ فعلية في المستقبل. تاريخ الحالة في MS Project أصبح سابقًا لتاريخ البيانات في P6. صحّحه وأعِد الحساب.
- رموز أنشطة مفقودة. راجع حقول Text المخصّصة؛ فالأداة المضبوطة جيدًا تضعها هناك. إذا حوّلت باستخدام المُصدِّر الأصلي في P6، فإنها لم تصل.
والعكس: من MPP إلى XER
للطريق العكسي فخاخه الخاصة. المهام في وضع Manually Scheduled (من MS Project 2010 فصاعدًا) لا تملك منطقًا حقيقيًا ويستوردها P6 بتواريخ ثابتة: حوّلها إلى Auto Scheduled قبل التصدير. الـ deadlines في MS Project غير موجودة في P6 فتضيع أو تتحوّل إلى قيود. كما تتحوّل المهام التلخيصية إلى مستويات WBS، لذا فإن بنية تلخيصية مضطربة تولّد WBS مضطربة بالقدر نفسه. يتناول المقال حول كيفية الترحيل من MS Project إلى Primavera P6 هذا الطريق بالتفصيل.
توصية تعاقدية: اتّفق منذ البداية على أيّ ملف هو "الرئيسي" وبأي صيغة يُتبادَل. ممارستنا هي تسليم ثلاثة أشياء معًا دائمًا: الملف الأصلي، والنسخة المحوَّلة، وملف PDF لمخطّط Gantt مع المسار الحرج. وهكذا لا يتجادل أحد حول النسخة المعتمدة.
التحويل الجيد ليس مشكلة تقنية صعبة؛ بل مسألة انضباط. بالأداة الصحيحة وقائمة التحقق، يكفّ عن كونه مخاطرة على المشروع ويصبح إجراءً روتينيًا من عشر دقائق.