طلب تقديم العروض (RFP) لتنفيذ Salesforce: الهيكل والأسئلة والنتائج الأساسية

ما الذي يجب أن يحققه طلب تقديم العروض الجيد (RFP)

الهدف من طلب تقديم العروض (RFP) ليس الحصول على سعر، بل الحصول على عروض قابلة للمقارنة وتحديد أي من الموردين قد فهم المشكلة بالفعل. وثيقة تفصل مائة متطلب وتطلب الإشارة إلى "متوافق / غير متوافق" تحقق عكس ذلك: جميع الموردين يشيرون إلى "متوافق"، ويتحول القرار إلى عامل السعر.

فرق عملي: بدلاً من كتابة "سيسمح النظام بإدارة الفرص"، صفوا أن الشركة تدير حوالي أربعمائة صفقة شهريًا، وأن كل صفقة تمر بموافقة تسعير، وأن الموافقة تتم حاليًا عبر البريد الإلكتروني. سيعيد الموردون إجابات مختلفة جدًا — وهذا هو جوهر الموضوع.

الأجزاء التسعة لوثيقة RFP خاصة بـ Salesforce

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

2. الوضع الحالي. الأنظمة المستخدمة، عدد المستخدمين، ما الذي يعمل حاليًا وما الذي لا يعمل. إذا كانت بيئة Salesforce موجودة، اذكروا الإصدار، عمرها، ومستوى التخصيص.

3. العمليات الأساسية ضمن النطاق. من ثلاث إلى سبع عمليات، كل منها في فقرة: من يقوم بالتنفيذ، ما هي نقاط القرار، وماذا يحدث عندما ينحرف شيء ما.

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

5. التكاملات. لكل نظام: الاسم، نوع الواجهة إذا كان معروفًا، الاتجاه، التردد المطلوب، ومن هو المالك داخل المنظمة.

6. القيود. اللوائح التنظيمية، أمن المعلومات، موقع التخزين، اللغات، سهولة الوصول، الجداول الزمنية غير القابلة للتغيير.

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

8. طريقة التقييم. معايير وأوزان، يتم الإعلان عنها مسبقًا. هذا يؤدي إلى عروض مركزة ويقلل من النزاعات بعد الفوز.

9. الجدول الزمني للمناقصة. موعد طرح الأسئلة، موعد الردود، موعد التقديم، موعد العروض التوضيحية، موعد القرار.

البيانات التي يجب الكشف عنها للحصول على تسعير حقيقي

الأسئلة التي تميز بين الموردين

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

• ما هي الافتراضات الرئيسية الثلاثة التي تستند إليها العرض، وما هو الأثر إذا كان أحدها خاطئًا.
• في أي الحالات توصون بالتهيئة (Configuration) بالرغم من أن التطوير (Development) سيكون أفضل، والعكس صحيح.
• صفوا مشروعًا تجاوزتم فيه الجدول الزمني. ما الذي تسبب في ذلك وما الذي غيرتموه منذ ذلك الحين.
• من سيكون أعضاء الفريق الفعليين، وما هي نسبة الوقت الذي يخصصه كل منهم لهذا المشروع.
• ما الذي تحتاجونه منا لتحقيق النجاح، وماذا ستفعلون إذا لم تحصلوا عليه.
• كيف ستنقلون لنا القدرة على صيانة النظام بدونكم.

السؤال الأخير هو اختبار جيد لطبيعة العلاقة. المورد الذي يتجنبه يخطط للاعتمادية.

ما يجب طلبه كناتج في العرض

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

العنصر الأخير ربما هو الأكثر تميزًا، لأنه يظهر مستوى العمل وليس مجرد وعد.

هيكل تسعير موحد — الأداة التي تمنع مقارنة التفاح بالبرتقال

حددوا بأنفسكم الجدول الذي يجب على كل مقدم عرض ملؤه:

المورد الذي يرفض تقسيم السعر وفقًا لهذا الهيكل ليس بالضرورة غاليًا — لكن لا يمكن مقارنته، وهذا سبب كافٍ للعودة إليه بطلب التوضيح.

مثال توضيحي: صندوق تقاعد متوسط الحجم

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

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

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

أخطاء شائعة في كتابة RFP (طلب تقديم العروض)

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

ماذا يحدث بعد التقديم

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

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

الخطوة التالية

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