اختبارات قبول CRM: سيناريوهات يجب تجربتها قبل الإطلاق

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

ما الذي يختبره القبول، وما الذي يسبقه؟

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

ومن هنا تأتي شروط الدخول إلى القبول، وتُكتب في الخطة: التهيئة مكتملة للنطاق المختبر، وتقرير اختبار التهيئة والتكامل مسلّم، وترحيل تجريبي محمّل في بيئة الاختبار، وحسابات اختبار جاهزة لكل دور، والمستخدمون الرئيسيون متاحون في المواعيد المتفق عليها. إن لم تتحقق الشروط يُؤجل القبول، ولا يُبدأ بنصف نظام.

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

تصميم السيناريوهات: ثلاث طبقات

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

الطبقة الأولى: سيناريوهات شاملة تعبر الأدوار

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

الطبقة الثانية: السيناريوهات اليومية لكل دور

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

الطبقة الثالثة: السيناريوهات السلبية والصلاحيات

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

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

كيف تُكتب حالة الاختبار؟ مثال كامل

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

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

البيانات وحسابات الاختبار

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

إدارة العيوب: التصنيف والفرق بين العيب وطلب التغيير

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

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

تنظيم الجولات

1. جلسة افتتاح

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

   مدير المشروع من الطرفين
2. الجولة الأولى

   تنفيذ كل السيناريوهات مرة واحدة، مع اجتماع فرز يومي للملاحظات. الهدف هنا الكشف لا الإصلاح.

   المستخدمون الرئيسيون
3. نافذة الإصلاح

   معالجة العيوب الحرجة والمرتفعة، وتقدير طلبات التغيير، وتسليم قائمة ما أُصلح.

   فريق التنفيذ
4. الجولة الثانية

   إعادة السيناريوهات الفاشلة وما يتصل بها، وتنفيذ السيناريوهات الشاملة كاملة مرة أخرى.

   المستخدمون الرئيسيون
5. محضر القبول

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

   مسؤول المشروع في المنشأة

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

قرار الإطلاق

يُتخذ القرار في اجتماع يحضره الراعي التنفيذي ومديرو الإدارات ومدير المشروع من الطرفين، على معايير كُتبت قبل بدء القبول لا بعده:

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

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

البداية من وثيقة الإجراءات

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

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

أسئلة شائعة