يصل مدير مكتب إدارة المشاريع إلى العرض التجريبي عادةً بعد أن ضيّق القائمة إلى ثلاثة موردين أو أربعة. وهنا يحدث الخطأ الأكثر شيوعًا: يترك كل مورد يعرض ما يتقنه بالترتيب الذي يفضله، فتخرج اللجنة بانطباعات عن واجهات جميلة ولوحات ملونة، دون أن تعرف هل يعالج أي نظام منها المشكلة التي بدأ الشراء من أجلها.
يعالج هذا الخطأ نص عرض تجريبي مكتوب يرسله المشتري قبل الموعد. وفيما يلي نص جاهز للتعديل يصلح لتجربة نظام إدارة المشاريع قبل الشراء: عشرة سيناريوهات تغطي مستويات العمل والأدوار، والبيانات التي ترسلها مع كل سيناريو، وقواعد إدارة الجلسة، والأسئلة التي تكشف الفرق بين ما يعمل فعلًا وما يُوعد به.
لماذا ترسل سيناريوهات مكتوبة بدل جولة عامة يختارها المورد؟
نص العرض التجريبي (Demo Script) هو مجموعة سيناريوهات مكتوبة يرسلها المشتري إلى كل المتنافسين قبل الموعد، يصف كل منها مهمة عمل حقيقية يطلب من المورد تنفيذها في النظام أمام اللجنة. الفرق بينه وبين الجولة العامة أن المشتري هو من يحدد ما يُعرض وترتيبه، لا المورد.
تكشف السيناريوهات المكتوبة ثلاثة أمور لا تكشفها الجولة العامة. الأول: هل يتحقق المتطلب بالتهيئة، أي بإعدادات داخل النظام، أم يحتاج تطويرًا إضافيًا لم يظهر في العرض المالي. الثاني: كم خطوة يحتاجها الدور ليؤدي عمله اليومي. الثالث: هل ترتبط البيانات فعلًا بين المستويات، فيظهر تحديث المهمة في المشروع ثم في البرنامج والمحفظة دون إدخال مكرر.
والسيناريوهات المكتوبة تحمي الجهة أيضًا. حين يُعرض على كل مورد التسلسل نفسه بالبيانات نفسها، تصبح المقارنة قابلة للدفاع أمام الإدارة العليا ولجنة فحص العروض، وتنتقل نتائجها مباشرة إلى مصفوفة تقييم عروض الموردين بدل أن تبقى انطباعات.
كيف تكتب سيناريو واحدًا يمكن تنفيذه وتقييمه؟
السيناريو الجيد قصير ومحدد، ويجيب عن ستة أسئلة. استخدم هذا القالب لكل سيناريو قبل أن ترسله:
- العنوان بصيغة «أرِنا كيف…»: فعل يُنفذ في النظام، مثل «أرِنا كيف يُرفع طلب تغيير ويُعتمد»، لا «هل يدعم النظام إدارة التغيير؟».
- الدور المنفذ: من يؤدي الخطوة في جهتك: مدير المحفظة، أو مدير البرنامج، أو مدير المشروع، أو المالية، أو عضو الفريق.
- البيانات الأولية: الأرقام والأسماء الافتراضية التي يستخدمها المورد، حتى يُنفذ كل الموردين السيناريو على الحالة نفسها.
- المخرج المتوقع: ما يجب أن تراه اللجنة في نهاية السيناريو، مثل ترتيب مبادرات أو تاريخ انتهاء جديد أو تقرير.
- الوقت المخصص: عدد الدقائق المسموحة، ثم دقائق محددة للأسئلة.
- ما لا يُقبل بديلًا: شرائح العرض التقديمي، أو مقطع مسجل، أو عبارة «يمكن عمل ذلك لاحقًا». السيناريو الذي لا يُنفذ أمامك يُسجَّل «لم يُعرض».
اكتب السيناريو بلغة عملك اليومية لا بلغة المتطلبات. عبارة «تقييم المبادرات بمعايير موزونة» تصبح: «أرِنا كيف نُدخل ست مبادرات ونقيّمها بمعاييرنا الأربعة وأوزانها، ثم نرى ترتيبها». الصيغة الثانية لا تحتمل جوابًا عامًا.
عشرة سيناريوهات للعرض التجريبي تغطي المحفظة والبرنامج والمشروع
الجدول التالي نص عرض مقترح يغطي المستويات الثلاثة والأدوار الرئيسية. عدّل البيانات لتطابق جهتك، واحذف ما لا يخص نطاق الشراء، وأضف ما يخص مشكلتك الأولى. إن كنت قد أعددت قائمة متطلبات شراء نظام لمكتب إدارة المشاريع، فاختر منها المتطلبات ذات الأولوية العالية وحوّلها إلى سيناريوهات، لا كل القائمة.
| # | السيناريو «أرِنا كيف…» | المستوى والدور | البيانات الأولية التي ترسلها | المخرج المتوقع |
|---|---|---|---|---|
| 1 | نسجّل مبادرة جديدة ونقيّمها بمعايير الأولوية الموزونة ونرتبها مع غيرها | المحفظة — مدير المحفظة | ست مبادرات بتقديراتها، وأربعة معايير أولوية بأوزان مجموعها 100% | ترتيب المبادرات الست ودرجة كل منها، وأثر تغيير وزن معيار واحد |
| 2 | نوزع ميزانية المحفظة مقابل سقفها ونرى ما يُؤجَّل ولماذا | المحفظة — مدير المحفظة والمالية | سقف ميزانية افتراضي أقل من مجموع طلبات المبادرات | المبادرات الممولة، والفجوة التمويلية، والمؤجَّل مع سبب التأجيل |
| 3 | يظهر أثر تأخر مشروع على مشروع آخر في البرنامج نفسه | البرنامج — مدير البرنامج | مشروعان بينهما اعتمادية «نهاية إلى بداية»، وتأخر 20 يوم عمل في الأول | المشروع المتأثر والتاريخ الجديد، والأهداف المهددة في البرنامج |
| 4 | ننشئ مشروعًا من قالب جهتنا ونرسله للاعتماد في مسارنا | المشروع — مدير المشروع والمعتمدون | نموذج طلب المشروع الحالي، ومسار اعتماد من ثلاثة مستويات | المشروع لدى المعتمد الأول، وسجل رحلة الطلب ومن اعتمده |
| 5 | نحدّث الإنجاز دوريًا ونرى المسار الحرج والانحراف عن خط الأساس | المشروع — مدير المشروع والمخطط | جدول من 25 نشاطًا بتقويم أيام عمل الجهة وإجازة رسمية، ونسب إنجاز لتاريخ محدد | المسار الحرج بعد التحديث، ومؤشر أداء الجدول، والمقارنة بخط الأساس |
| 6 | نسجّل مصروفًا يتجاوز حد التفويض ونرى تصعيده وأثره على التكلفة المتوقعة | المشروع — المالية ومدير المشروع | ميزانية مشروع وبنود تكلفة، ومصروف يتجاوز حد المستوى الأول | مسار التصعيد، ومؤشر أداء التكلفة، والتكلفة المتوقعة عند الإنجاز |
| 7 | يتحول خطر إلى قضية ويُصعَّد وفق قواعدنا | المشروع والبرنامج — مدير المشروع | خطر بتقييم احتمال وأثر، ومؤشر إنذار بقيمة حدية تُتجاوز | القضية المرتبطة بالخطر، ومستوى التصعيد، وظهورها في سجل البرنامج |
| 8 | يمر طلب تغيير يمدد الجدول ويرفع التكلفة حتى يصدر خط أساس جديد | المشروع — مدير المشروع ولجنة التغيير | طلب تمديد شهر بتكلفة إضافية افتراضية | تحليل الأثر، وقرار اللجنة، وإصدار خط أساس جديد مع بقاء السابق |
| 9 | يرى كل دور ما يخصه فقط | كل المستويات — مسؤول المنصة | ثلاثة مستخدمين: مدير مشروع في إدارة، ومدير إدارة أخرى، وعضو في الإدارة العليا | الدخول بكل حساب وعرض ما يراه وما يُمنع عنه |
| 10 | يُبنى تقرير الحالة الشهري للإدارة العليا دون تجميع يدوي ويُجدول إرساله | المحفظة — مكتب إدارة المشاريع | بيانات الحزمة نفسها بعد السيناريوهات السابقة | تقرير يجمع المشاريع والبرامج، وجدولة إرساله لمستلمين محددين |
السيناريوان 5 و6 يستخدمان مؤشرين يحتاجان تعريفًا موحدًا قبل الجلسة. مؤشر أداء الجدول (SPI) هو القيمة المكتسبة مقسومة على القيمة المخططة، ومؤشر أداء التكلفة (CPI) هو القيمة المكتسبة مقسومة على التكلفة الفعلية؛ والقيمة أقل من 1 تعني تأخرًا أو تجاوزًا. اطلب من المورد أن يبين من أين يقرأ النظام كل رقم، لا أن يعرض المؤشر وحده.
لاحظ أن السيناريو 5 يختبر أيضًا التقويم: إن كانت جهتك تعمل بالتقويم الهجري أو بتقاويم مختلفة لفرق ومواقع، فاذكر ذلك في البيانات الأولية. وكل السيناريوهات العشرة تختبر الواجهة العربية من اليمين إلى اليسار في النماذج والتقارير، لا في الشاشة الرئيسية وحدها.
ولتعرف قبل الجلسة كيف تبدو مخرجات بعض هذه السيناريوهات في منصة متكاملة، اطّلع على وحدة إدارة المحافظ وتقييم المبادرات وأولوياتها للسيناريوهين 1 و2، ووحدة إدارة طلبات التغيير وخطوط الأساس للسيناريو 8.
ما البيانات الأولية التي ترسلها مع النص، ومتى؟
حزمة البيانات الأولية هي الملف الذي يجعل السيناريوهات متطابقة بين الموردين. جهّزها مرة واحدة وأرسلها للجميع في اليوم نفسه، مع مهلة متساوية قبل الموعد تكفي لإعداد البيانات في النظام، ويحددها فريقك حسب حجم الحزمة.
- هيكل مبسط: محفظة واحدة، وبرنامج أو اثنان، وثلاثة مشاريع أو أربعة، بأسماء افتراضية.
- أرقام افتراضية: ميزانيات وتواريخ ونسب إنجاز معدّلة عن الواقع، لا بيانات مشاريع حقيقية. صنّف الحزمة وفق سياسة تصنيف البيانات في جهتك قبل إرسالها.
- نماذجك الحالية: نموذج طلب المشروع، ونموذج تقرير الحالة الشهري، ومسار الاعتماد كما هو مكتوب اليوم.
- قواعدك: معايير الأولوية وأوزانها، وحدود التفويض المالي، وقواعد تصعيد المخاطر.
- قائمة الحضور وأدوارهم: حتى يعرف المورد من سينفذ كل سيناريو بحسابه.
اطلب من كل مورد أن يذكر في بداية الجلسة هل أدخل الحزمة في النظام أم استخدم بيانات توضيحية مشابهة من عنده. كلا الأمرين مقبول إذا قيل صراحة، لكنه يغيّر ما تستنتجه اللجنة: إدخال البيانات أمامكم يختبر سهولة الإدخال، أما البيانات المعدّة مسبقًا فتختبر المنطق والنتائج فقط.
منصة إدارة المشاريع والبرامج والمحافظ مثلًا تستخدم في عرضها التجريبي بيانات توضيحية، وتُعدّه على سيناريوهات قريبة من عمل الجهة. إن أردت التركيز على مثال من مشاريعك أو على سيناريوهات نصك المكتوب، فاذكر ذلك في طلبك عبر صفحة طلب العرض التجريبي لتُناقش طريقة تناوله عند تحديد الموعد.
قواعد إدارة الجلسة: التسلسل والتوقيت ومن يحضر
النص المكتوب لا يكفي إذا أُدير كل عرض بطريقة مختلفة. اتفق داخليًا على هذه القواعد، وأبلغ بها الموردين مع النص:
- التسلسل نفسه لكل مورد: لا يُقدَّم سيناريو ولا يُؤخَّر بطلب المورد، حتى يرى المقيّمون الأنظمة في اللحظة نفسها من القصة.
- مقدمة قصيرة محددة: عشر دقائق للمورد يعرّف فيها بنفسه ونظامه، ثم يبدأ النص.
- مدير وقت من اللجنة: عضو واحد يعلن انتهاء وقت السيناريو وينقل الجلسة إلى التالي، ولا يُعوَّض الوقت الضائع في سيناريو بأخذه من غيره.
- الأسئلة في نهاية كل سيناريو: دقائق محددة بعد كل سيناريو، لا أثناءه، حتى لا يتحول العرض إلى نقاش يستهلك الوقت.
- لا سيناريوهات إضافية أثناء الجلسة: السؤال الجديد يُكتب ويُرسل بعد الجلسة لكل الموردين بالصيغة نفسها.
- الحضور حسب السيناريو: لا يلزم أن يحضر الجميع الجلسة كاملة. قسّمها إلى كتل، ليحضر كل دور ما يخصه.
- تقييم فوري: يملأ كل حاضر تقييمه عقب كل سيناريو مباشرة، قبل نقاش اللجنة، بطريقة تشرحها مقالة بطاقة تقييم العرض التجريبي.
وأهم الحاضرين من سيستخدم النظام يوميًا: مدير مشروع من إدارة تنفيذية، وموظف من المالية إذا كان سيناريو التكلفة في النطاق، ومسؤول الصلاحيات من التقنية. حضور صاحب القرار وحده يجعل الأسئلة عامة، وحضور المستخدمين يجعلها دقيقة.
أسئلة تطرحها بعد كل سيناريو لتفرّق بين ما يعمل وما يُوعد به
الدقائق المخصصة للأسئلة بعد كل سيناريو تكشف أحيانًا أكثر مما يكشفه العرض نفسه إذا استُخدمت جيدًا. هذه الأسئلة تصلح لأي سيناريو:
- هل ما رأيناه يعمل بإعدادات النظام الحالية، أم بتهيئة خاصة لهذا العرض، أم يحتاج تطويرًا؟
- من في جهتنا يستطيع تعديل هذا الإعداد بعد الإطلاق: مسؤول المنصة، أم المورد وحده؟
- كم خطوة نفذها الدور حتى وصل إلى المخرج، وهل تتكرر هذه الخطوات يوميًا أم مرة واحدة؟
- أين يُحفظ أثر هذه العملية في سجل التدقيق، ومن يستطيع الاطلاع عليه؟
- ماذا يحدث لو رُفض الطلب في المستوى الثاني من الاعتماد، أو غاب المعتمد؟
وإذا ذكر المورد قدرة لم يعرضها، فلا تناقشها في الجلسة. اكتبها في قائمة «قيلت ولم تُعرض» واطلب الإجابة عنها كتابيًا أو عرضها في جلسة متابعة. ينطبق ذلك خصوصًا على البنود التي يصعب التحقق منها بالكلام: تكامل مع نظام بعينه لديك، أو تطبيق جوال، أو صيغ تصدير محددة، أو العمل دون اتصال. اطلب رؤيتها أو صياغتها بندًا مكتوبًا في العرض الفني.
ولأسئلة الشراء العامة التي لا تحتاج عرضًا، مثل الاستضافة وملكية البيانات والتدريب والدعم، راجع إجابات الأسئلة الشائعة عن المنصة والتطبيق والشراء قبل الجلسة، وخصص وقت العرض لما يجب أن يُرى.
مثال توضيحي: تقسيم جلسة السيناريوهات العشرة حسب الحضور
مثال توضيحي: مجموعة قابضة في الخبر تدير محفظة مشاريع واحدة تضم 3 برامج و31 مشروعًا موزعة على أربع شركات تابعة، وقد ضيّقت القائمة إلى ثلاثة موردين. الافتراضات: مدة كل سيناريو بين 10 و20 دقيقة حسب تعقيده، و5 دقائق أسئلة بعد كل سيناريو، و10 دقائق افتتاحية، و15 دقيقة ختامية للخطوات التالية.
الأسئلة = 10 سيناريوهات × 5 دقائق = 50 دقيقة
المدة الكلية = 10 + 135 + 50 + 15 = 210 دقائق لكل مورد
بدل أن تطلب المجموعة من الرئيس التنفيذي حضور ثلاث ساعات ونصف مع كل مورد، قسّمت الجلسة إلى ثلاث كتل بالترتيب نفسه لكل مورد:
- كتلة الإدارة العليا ومكتب المشاريع (65 دقيقة): الافتتاحية 10 دقائق، ثم السيناريوهات 1 و2 و10 (40 دقيقة) مع أسئلتها (15 دقيقة).
- كتلة مديري البرامج والمشاريع (95 دقيقة): السيناريوهات 3 و4 و5 و7 و8 (70 دقيقة) مع أسئلتها (25 دقيقة).
- كتلة المالية والتقنية (50 دقيقة): السيناريوهان 6 و9 (25 دقيقة) مع أسئلتهما (10 دقائق)، ثم الختام 15 دقيقة.
المجموع 65 + 95 + 50 = 210 دقائق، وهو ما حسبته المعادلة. حضر الرئيس التنفيذي الكتلة الأولى وحدها، وحضر مديرو المشاريع من الشركات الأربع الكتلة الثانية. ولأن السيناريو 10 يحتاج بيانات السيناريوهات الأخرى، طلبت المجموعة من الموردين أن يُدخلوا حزمة البيانات قبل الجلسة، وخصصت الكتلة الثانية لاختبار الإدخال المباشر.
النتيجة المتوقعة من هذا الترتيب ثلاث جلسات متطابقة البنية في ثلاثة أيام، وبطاقات تقييم معبأة لكل سيناريو من الحاضرين المعنيين به، وقائمة مكتوبة بالادعاءات غير المعروضة لكل مورد. هذه المخرجات هي مدخلات التقييم الفني، وتُجمع درجاتها في المصفوفة الموزونة بعد ذلك.