كيف تكتب وثيقة متطلبات CRM للحصول على عروض قابلة للمقارنة؟

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

لماذا تصل العروض غير قابلة للمقارنة؟

حين ترسل لثلاثة موردين رسالة تقول «نحتاج نظام CRM لفريق المبيعات والخدمة، مع ربط واتساب والمحاسبة»، تصلك ثلاثة عروض لا يمكن وضعها في جدول واحد. ليس لأن الموردين غير جادين، بل لأن كل واحد منهم ملأ الفراغات بافتراضاته:

• افترض كل مورد نطاقًا مختلفًا: أحدهم سعّر خمسة عشر مستخدمًا وآخر سعّر عشرين، وأحدهم أدخل الترحيل وآخر تركه «حسب الحاجة».
• ردّ كل مورد بطريقته: عرض فيه قائمة ميزات تسويقية، وآخر فيه جدول بحالات «نعم» و«لا»، وثالث فيه وصف عام للمنصة.
• فُهمت العبارة نفسها بثلاثة معانٍ: «ربط المحاسبة» قد تعني عند مورد تصدير ملف شهري، وعند آخر مزامنة لحظية في الاتجاهين.
• غابت طريقة التحقق: لا أحد يستطيع أن يثبت أنه أوفى بمتطلب لم يُحدَّد كيف يُختبر.

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

هيكل الوثيقة قسمًا قسمًا

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

1. التعريف بالمنشأة والأهداف

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

2. النطاق وحدوده

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

3. المستخدمون والأدوار

جدول بالأدوار (مندوب، مشرف، موظف خدمة، مدير، مسؤول نظام، مستخدم اطلاع)، وعدد كل دور الآن وبعد سنتين، ومن يعمل من الجوال، ومن في أي فرع. هذا الجدول وحده يزيل أكبر مصدر للاختلاف في التسعير.

4. الإجراءات الحالية والسيناريوهات

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

5. المتطلبات الوظيفية

مقسمة حسب المجال: العملاء وجهات الاتصال، والعملاء المحتملون، والفرص، والعروض، والعقود، والتواصل، والخدمة، والتقارير، والأتمتة. لكل متطلب رقم ثابت (FR-001...)، وأولوية، والسيناريو الذي يعود إليه. صيغة كتابة المتطلب في القسم التالي.

6. المتطلبات غير الوظيفية

ما لا يظهر في سيناريو بعينه لكنه يحكم النظام كله: دعم العربية في الواجهة والبحث والقوالب والتقارير، والصلاحيات على مستوى السجل والحقل، وسجل التدقيق، وضوابط التصدير، وخيار الاستضافة وموقع البيانات، والنسخ الاحتياطي والاستعادة، والدخول الموحد إن وُجد لديكم. رقّمها بسلسلة مستقلة (NFR-001...).

7. التكامل

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

8. البيانات والترحيل

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

9. الخدمات

ما تتوقعه من المورد: دراسة الإجراءات، والتهيئة، والترحيل التجريبي، واختبارات القبول، والتدريب حسب الدور مع عدد المتدربين، وتأهيل مسؤول النظام، ودعم ما بعد الإطلاق، ومستوى الدعم المستمر وساعاته، ومدة الضمان.

10. تعليمات الرد

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

11. معايير التقييم

المعايير التي ستقيّم بها العروض، ومعايير الإقصاء التي يُستبعد العرض إن لم يحققها. طريقة بناء هذه المعايير وأوزانها مفصلة في مقالة كيف تختار نظام CRM لشركتك في السعودية، والمطلوب هنا أن تعلن للموردين على الأقل ما الذي سيُقيَّم.

صيغة المتطلب القابل للاختبار

المتطلب الجيد يُكتب بحيث يستطيع شخص من خارج المشروع أن يختبره ويقول «تحقق» أو «لم يتحقق» دون نقاش. الصيغة العملية تتكون من خمسة عناصر:

1. من

   الدور الذي ينفذ الإجراء أو يستفيد منه: المندوب، أو المشرف، أو النظام نفسه عند حدث.

2. عند أي شرط

   الحدث أو الحالة التي تسبق الإجراء: عند وصول رسالة، أو عند تجاوز الخصم حدًا، أو عند مرور مدة.

3. ماذا يحدث

   الإجراء بفعل واحد واضح، لا عدة أفعال في جملة واحدة.

4. النتيجة المتوقعة

   ما يجب أن يُرى أو يُسجَّل بعد الإجراء، بكميات أو مدد إن لزم.

5. طريقة التحقق

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

الجدول التالي يعرض متطلبات مكتوبة بالطريقة الشائعة، وإعادة صياغتها بالعناصر الخمسة:

ومع الصيغة الخماسية، التزم بقواعد صغيرة توفر كثيرًا من النقاش لاحقًا:

• متطلب واحد في كل سطر: إذا احتوت الجملة على «و» تربط فعلين مستقلين فافصلهما، لأن المورد قد يحقق أحدهما دون الآخر.
• اكتب ماذا لا كيف: «يُمنع إنشاء عميل مكرر بالسجل التجاري نفسه» أفضل من «أريد زر تحقق بجانب الحقل»، فقد يكون لدى المورد طريقة أفضل للوصول إلى النتيجة نفسها.
• أرقام لا صفات: استبدل «سريع» و«كبير» و«كثير» بمدة أو عدد أو حجم.
• أولوية لكل متطلب: إلزامي، أو مهم، أو مرغوب. الإلزامي وحده يصلح معيار إقصاء. طريقة الفرز بين الإدارات دون خلاف في مقالة كيف ترتب أولويات متطلبات CRM.
• ربط بالسيناريو: متطلب لا يعود إلى سيناريو قد يكون رغبة شخصية لا حاجة تشغيلية. اسأل عنه قبل أن يدخل الوثيقة.

مصفوفة الاستجابة: شكل الرد الذي تفرضه على المورد

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

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

وأكواد الاستجابة المقترحة سبعة، وتعريف كل منها يُكتب في الوثيقة حتى لا يفسره كل مورد على هواه:

القاعدة التي يوضحها المثال: الكود وحده لا يكفي. كل «م» أو «إ» بلا طريقة تحقيق ولا دليل تُعاد إلى المورد قبل التقييم. وكل «ت» أو «ك» يجب أن يقابلها بند في العرض المالي، وإلا فهي تكلفة ستظهر بعد التعاقد. أما توحيد الأسعار نفسها وحساب تكلفة البنود الناقصة في كل عرض، فهو خطوة لاحقة تشرحها مقالة مقارنة عروض أسعار CRM على أساس النطاق.

الكميات والافتراضات التي يجب أن تحددها أنت

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

إن لم تعرف رقمًا بدقة، فاكتب تقديرًا ونطاقًا («بين 8,000 و10,000 سجل عميل»)، واطلب أن يوضح كل مورد أثر تجاوز النطاق على السعر. التقدير المعلن للجميع أفضل من دقة لا يعرفها إلا مورد واحد سألك عنها في اتصال جانبي.

كيف تُكتب الوثيقة ومن يشارك فيها؟

الوثيقة لا يكتبها شخص واحد من مكتبه. المسار العملي خمس خطوات:

1. ورش قصيرة لكل إدارة

   ساعة إلى ساعتين مع المبيعات، والخدمة، والتسويق، والمالية، وتقنية المعلومات. المخرج: خريطة الدورة الحالية، والسيناريوهات، والمشكلات التي يريدون حلها.

   مدير المشروع
2. المسودة الأولى

   كتابة الأقسام الأحد عشر، وتحويل ما قيل في الورش إلى متطلبات مرقمة بالصيغة الخماسية.

   مدير المشروع مع محلل من تقنية المعلومات
3. مراجعة الإدارات والأولويات

   كل إدارة تراجع متطلباتها وتتفق مع البقية على الأولوية. أي متطلب بلا سيناريو يُسأل عنه أو يُحذف.

   رؤساء الإدارات
4. التجميد والإصدار

   اعتماد الوثيقة برقم إصدار وتاريخ، وإرسال النسخة نفسها لجميع الموردين في الوقت نفسه.

   الراعي من الإدارة العليا
5. سجل الاستفسارات

   تُجمع أسئلة الموردين حتى موعد محدد، ويُرد عليها في ملحق واحد يصل للجميع، ويصبح الملحق جزءًا من الوثيقة.

   المشتريات

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

أخطاء تفسد قابلية المقارنة

• نسخ قائمة ميزات من موقع مورد: تتحول الوثيقة إلى وصف لنظام بعينه، فيحصل على الدرجة الكاملة ويبدو غيره ناقصًا، دون أن يُختبر أي منهم على عملكم.
• مئات المتطلبات كلها إلزامية: حين يكون كل شيء إلزاميًا لا يعود التصنيف يميز شيئًا، ويضطر الموردون إلى الإجابة بـ«نعم» عامة ليبقوا في المنافسة.
• إغفال المتطلبات غير الوظيفية: يُقارن الموردون على الشاشات، ثم تظهر بعد الترسية فروق في الاستضافة والصلاحيات والنسخ الاحتياطي.
• ترك صيغة الرد حرة: تصل ثلاثة عروض بثلاثة أشكال، ويقضي فريق التقييم أيامًا في نقلها إلى جدول واحد، مع احتمال الخطأ في النقل.
• عدم ربط الوثيقة بالعقد: تُكتب الوثيقة بعناية، ثم يُوقَّع عقد يشير إلى «النظام حسب العرض» بدل مصفوفة الاستجابة المعتمدة، فتفقد الإجابات قوتها الإلزامية.

بعد اكتمال الوثيقة

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

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

أسئلة شائعة