كراسة الشروط الفنية (RFP) مرشّح، والكراسة المبهمة ترشّح الشيء الخطأ: المورّد الذي يملك أبرع كتّاب عروض، لا أفضل المهندسين. يغطي هذا المقال المهام الثلاث التي يجب أن تؤدّيها الكراسة الجيدة، ومثالاً محسوباً، والفخاخ التي تحوّل المشتريات المتأنّية إلى مشتريات مكلفة.
هكذا يجري الأمر عادةً. تسرد كومةً من الميزات، وتطلب بعض الشهادات، وتطلب أقل سعر. تعود إليك خمس وثائق واثقة كلها متشابهة. وبعد بضعة أشهر، يأتي العرض «الفائز» متأخراً، متجاوزاً للميزانية، ويؤدّي العمل الخطأ ببراعة.
هذا ليس سوء حظ، بل هو المعدّل الطبيعي. تكشف أبحاث CHAOS من Standish Group أن نحو 31% من المشاريع تنجح، ونحو 50% «متعثّرة» (متأخرة أو متجاوزة للميزانية أو منقوصة النطاق)، ونحو 19% تفشل تماماً (InfoQ, 2015). وكلما كبرت الميزانية ساءت الاحتمالات: درست McKinsey مع Oxford أكثر من 5,400 مشروع تقني، فوجدت أن الكبيرة منها تتجاوز الميزانية في المتوسط بنسبة 45% وتقدّم قيمة أقل بنسبة 56% مما كان متوقعاً (McKinsey, 2012). وقدر كبير من هذا الضرر يتقرّر في الوثيقة التي اختارت المورّد.
المهام الثلاث التي يجب أن تؤدّيها كراسة الشروط
نحِّ قوالب المشتريات جانباً، فلن تجد لكراسة الشروط سوى ثلاث مهام. أدِّها كلها فترشّح المورّدين نيابةً عنك. أهمل واحدة فيحدث الترشيح في اجتماع المبيعات بدلاً من ذلك.
flowchart TD A(["كراسة الشروط الفنية"]) --> B(["أولاً: اذكر المشكلة، لا الحل"]) A --> C(["ثانياً: اجعل كل متطلب قابلاً للاختبار"]) A --> D(["ثالثاً: ثبّت التقييم قبل وصول العروض"]) B --> B2(["إن أُهملت: يبيعك المورّدون منتجهم، لا نتيجتك"]) C --> C2(["إن أُهملت: خمس إجابات «نعم» متطابقة لا تميّز بينها"]) D --> D2(["إن أُهملت: يفوز من قدّم آخراً"])
المهمة الأولى: اكتب المشكلة، ثم دع المورّدين يقترحون الطريقة
افتتح بما تحاول تحقيقه والقيود العالق فيها. لا قائمة ميزات، بل بيان مشكلة يستطيع مهندس أن يجادل فيه.
- النتيجة. «تقليص المدة من الطلب إلى الشحن من ثلاثة أيام إلى يوم واحد» مشكلة. أما «نظام مستودعات مع مسح ضوئي بالجوال» فحلّ اخترته مسبقاً، وربما كان الحل الخطأ.
- الحجم. عدد المستخدمين، والمعاملات يومياً، وحجم البيانات اليوم وبعد ثلاث سنوات. يحدّد المورّدون معماريتهم وسعرهم بناءً على هذا. أغفله فيصبح كل عرض تخميناً.
- التكاملات. سمِّ الأنظمة التي يجب أن يتواصل معها: نظام تخطيط الموارد (ERP)، والبنك، والفوترة الإلكترونية لدى هيئة الزكاة والضريبة والجمارك (ZATCA). وسمِّ الأنظمة التي لا واجهة برمجية (API) لها. تلك القائمة هي حيث تموت المشاريع.
- الأنظمة التي تخضع لها. دخل نظام حماية البيانات الشخصية (PDPL) حيّز النفاذ في 14 سبتمبر 2023 وجهته المنظِّمة سدايا (SDAIA)، ويخضع النقل عبر الحدود للمادة 29 ولوائح النقل الصادرة عن سدايا (Morgan Lewis, 2024). فاذكر أين يجوز استضافة البيانات الشخصية وهل يجوز خروجها من المملكة. وإن كنت خاضعاً للضوابط الأساسية للأمن السيبراني من الهيئة الوطنية للأمن السيبراني (NCA ECC)، فاسرد الضوابط التي يرثها المورّد. البنك يسمّي ساما (SAMA)، والمستشفى يسمّي نفيس (NPHIES).
- القيود. نطاق الميزانية، وموعد الإطلاق الذي يهم فعلاً، وما لا تستطيع تغييره: مركز البيانات، ومزوّد الهوية، والنظام الحالي.
ثم توقّف. دع المورّدين يخبرونك كيف. أفرط في تحديد الحل فتقتل الأفكار الأفضل وتدعو إلى ملء الخانات. وإن كنت جهة حكومية فالمنافسة تُطرح عبر منصة اعتماد بصيغة ثابتة، لكن لا شيء يمنعك من وضع بيان مشكلة حقيقي في الملحق الفني.
المهمة الثانية: اجعل كل متطلب قابلاً للاختبار
عبارة «يجب أن يكون النظام قابلاً للتوسّع» لا تعني شيئاً. لا أحد يستطيع تقييمها، فيكتب كل مورّد «نعم». جرّب هذا بدلاً منها: «يجب أن يتحمّل 5,000 مستخدم متزامن مع تحميل الصفحات في أقل من 300 مللي ثانية، مثبتاً على نشر إنتاجي محدّد الاسم نستطيع الرجوع إليه». الآن يستطيع المورّد إثباته وتستطيع أنت التحقق منه. والاختبار لكل سطر: هل يعطيه مقيّمان يعملان منفصلين الدرجة نفسها؟
- استبدل بالصفات شروطاً. تصبح «آمن»: «يشفّر البيانات المخزّنة والمنقولة، ويدعم تسجيل الدخول الموحّد (SSO) مع مزوّد الهوية لدينا، واجتاز اختبار اختراق مستقلاً خلال الاثني عشر شهراً الأخيرة».
- سمِّ الواجهة الفعلية. «يرحّل قيود اليومية إلى SAP عبر واجهة BAPI القياسية، مع طابور أخطاء موثّق». المورّد الذي فعلها سيقولها بالتفصيل.
- افصل الإلزامي عن المُقيَّم. المتطلب الإلزامي بوابة: من يخفق فيه يخرج عرضه مهما كان السعر. توطين البيانات داخل المملكة، وشهادة مطلوبة، وموعد إطلاق صارم. وكل ما عدا ذلك يأخذ درجة مرجّحة. الخلط بينهما هو ما يُدخل عرضاً رخيصاً يخفق في متطلب نظامي إلى القائمة المختصرة.
- اطلب أدلّة، لا صفات. مخطط معمارية لحالتك أنت. مشروع محدّد الاسم بحجم مماثل مع مرجع تستطيع الاتصال به. والسير الذاتية للمهندسين الذين سينفّذون العمل، لا الشريك الذي يظهر في الانطلاقة ثم يختفي. والأسئلة المحرجة: كيف تتعاملون مع ترحيل البيانات، وكيف تسعّرون طلبات التغيير؟
المهمة الثالثة: ثبّت التقييم قبل وصول أول عرض
اتفقوا على أوزانكم الآن، وأنتم هادئون ولا أحد في الغرفة يبيع لكم. فبمجرد أن تبدأ العروض التوضيحية، خسرت. ستكافئ من قدّم آخراً.
حرّك الأرقام بما يناسب وضعك؛ فالبنك يرفع وزن المخاطر. الغاية أنك تحدّدها أولاً، وتنشرها في الكراسة، وتجعل كل مقيّم يقيّم باستقلال قبل أن يقارن أحد ملاحظاته. والآلية كاملة في إطارنا لتقييم عروض البرمجيات.
قاعدة أخيرة: السعر درجة من الدرجات، لا الدرجة كلها. العرض الأرخص لا يكاد يكون النظام الأرخص أبداً. قيّم التكلفة الإجمالية على خمس سنوات: الترخيص، والتنفيذ، والتكامل، والدعم، والموظفين الداخليين، وما يكلّفك استرجاع بياناتك. نتعمّق في هذا في التكاليف الخفية لبرمجيات المؤسسات.
مثال محسوب: ثلاثة عروض لنظام واحد
لنفترض أنك موزّع يستبدل نظام مستودعات في أربعة مواقع. الأرقام افتراضية لتوضيح الشكل.
تصل ثلاثة عروض. المورّد «أ» يعرض 900,000 ريال، وهو الأقل. المورّد «ب» يعرض 1.4 مليون ريال. المورّد «ج» يعرض 1.9 مليون ريال مع شعار معروف. بالسعر وحده، يفوز «أ».
الآن طبّق الكراسة. يخفق «أ» في بوابة إلزامية: منصته مستضافة خارج المملكة وإجابته عن توطين البيانات كانت «يمكننا النظر في ذلك». يخرج قبل أن يبدأ التقييم. وفي الملاءمة الفنية يتفوّق «ب» على «ج»: معماريته رُسمت لمواقعك الأربعة، ومرجعه موزّع بحجمك، والمهندس المسمّى في العرض كان حاضراً في مكالمة المرجع. أما عرض «ج» فكان مصقولاً لكنه عام.
وفي التكلفة، كان ترخيص «ج» أقل، لكن أسعار طلبات التغيير لديه أعلى، وعقده يجعل تصدير البيانات خدمة مدفوعة، فجاء إجمالي «ب» على خمس سنوات أقل من إجمالي «ج». يفوز «ب» بورقة تقييم تستطيع عرضها على مجلس الإدارة، وسبب عدم اختيارك للعرض الأرخص مكتوب قبل أن يسأل أحد. لم يحتج أيّ من هذا إلى ميزانية أكبر، بل إلى وثيقة أفضل.
أين تخفق كراسات الشروط
نرى أنماط الإخفاق الخمسة نفسها في أغلب المنافسات التي يُطلب منا إنقاذها.
- نسخ قالب مورّد. إذا «ساعدك» مورّد في صياغة متطلباتك، فالكراسة تحدّد منتجه. يرى كل منافس ذلك في الصفحة الأولى ويقدّم عرضاً ليخسر.
- مئتا متطلب، ولا واحد قابل للاختبار. الكراسات الطويلة تبدو صارمة. وعملياً يجيب المورّدون بـ«ملتزم» عن كل شيء، فيعود القرار إلى السعر.
- التقييم بعد القراءة. الأوزان التي تتقرّر بعد العروض التوضيحية تبرير، لا تقييم، ولا يمكن الدفاع عن الترسية إن طُعن فيها.
- الأرخص يفوز. نظام يخدم خمس سنوات يُشترى بسعر السنة الأولى، وهذا يعني عادةً أنحف فريق تنفيذ وأعلى أسعار لطلبات التغيير.
- لا بند خروج. إن لم تشترط الكراسة تصديراً موثّقاً للبيانات وتسليماً محدّداً، فالمورّد يملك بياناتك عملياً. الارتهان يتقرّر عند التوقيع، لا عند التجديد. وبنود العقد التي تُبقي خياراتك مفتوحة في تجنّب الارتهان للمورّد في التقنية الحكومية.
اللبس الصادق: كتابة كراسة جيدة تستغرق وقتاً أطول، من ثلاثة إلى ستة أسابيع بحسب تجربتنا، وبعض المورّدين سيرفضون العمل الإضافي. هذا هو المرشّح يعمل.
كيف تبدأ: كراسة واحدة، بالطريقة الصحيحة
النمط الناجح ممل وموثوق. اختر مشتريات واحدة مهمة. اكتب بيان المشكلة أولاً واجعل من سيعيش مع النظام يعتمده. حوّل المتطلبات إلى اختبارات، وافصل الإلزامي عن المُقيَّم، وحدّد الأوزان. وعندها فقط افتح الباب للمورّدين. نفّذ التقييم كما كُتب، واحتفظ بأوراق التقييم.
ثم قِس: هل انتهى المشروع ضمن ميزانيته وموعده، وهل كانت ورقة التقييم لتتنبّأ بالفائز؟ إن كان الجواب نعم، فتلك الكراسة قالبك للمنافسة التالية. وإن كان لا، فقد تعلّمت أي متطلب أغفلت، وبثمن رخيص. والقراءة المستقلة للوثيقة قبل إصدارها هي ما تقدّمه ممارستنا في التقييم التقني والعناية الواجبة التقنية.
هل على مكتبك كراسة شروط لست واثقاً أنها ستجلب لك المورّد المناسب؟ تكتب SDCG كراسات الشروط الفنية وتقيّمها كطرف مستقل، دون أي عمولات من المورّدين. احجز استشارة مجانية لمدة 30 دقيقة وسنختبر كراستك تحت الضغط قبل إصدارها، أو نساعدك في تقييم العروض التي وصلتك بالفعل.