- حين يتقارب نظامان في التقييم الورقي والعروض، لا يحسم القرارَ عرضٌ إضافي. الذي يحسمه إثبات مفهوم محكوم (Proof of Concept): فريقكم يعمل بنفسه على النظامين بالسيناريوهات والبيانات والمدة نفسها.
- الإحكام يعني ثبات كل شيء ما عدا النظام: عينة البيانات، والمستخدمون، والمهام، ومقدار مساعدة المورد، وقناة الأسئلة. أي اختلاف في هذه يجعل النتيجة مقارنة بين ظروف لا بين نظامين.
- قيسوا ما يمكن قياسه: نسبة إنجاز المهام دون مساعدة، ووقت المهام اليومية، وقدرة مسؤول النظام على تعديل الإعدادات، واختبار تكامل مصغر، وسرعة استجابة المورد. ثم حوّلوا القياسات إلى درجات على معاييركم الموزونة.
- اتفقوا قبل البدء على قاعدة الحسم: متى يُعد الفرق حاسمًا، ومتى يُعد تعادلًا يُحسم بالمخاطر والتكلفة.
تفترض هذه المقالة أنكم أنهيتم التقييم الأولي ووصلتم إلى نظامين نهائيين. ستجد فيها متى يستحق إثبات المفهوم جهده، وكيف تصممونه بحيث تكون المقارنة عادلة، وما الذي تقيسونه في كل يوم منه، وكيف تنتهون إلى بطاقة نهائية بمثال محسوب، والأخطاء التي تفسد نتيجته.
لماذا لا يكفي عرض توضيحي ثالث؟
في العرض التوضيحي يقود المورد، ويعرف النظام جيدًا، ويختار أقصر طريق لكل مهمة. هذا مفيد لاختبار الملاءمة، وهو موضوع سيناريو العرض التوضيحي الذي تفرضونه على الموردين. لكنه لا يجيب عن ثلاثة أسئلة تبقى مفتوحة بين نظامين متقاربين:
- هل يستطيع فريقنا العمل عليه بنفسه؟ المندوب الذي لم يرَ النظام من قبل، لا مقدم العرض الذي يستخدمه كل يوم.
- هل نستطيع تعديله بعد الإطلاق دون المورد؟ إضافة حقل وقاعدة تنبيه وتقرير على يد مسؤول النظام لديكم.
- كيف يتصرف المورد حين نحتاجه؟ سرعة الإجابة ودقتها حين يتعثر المستخدم، وهي أقرب صورة لما سيكون عليه الدعم.
إطار المعايير والأوزان وطريقة التسجيل من 0 إلى 4 مشروح في مقالة كيف تختار نظام CRM لشركتك في السعودية. إثبات المفهوم لا يستبدل هذا الإطار، بل يعيد تسجيل المعايير التي بقيت درجاتها مبنية على كلام المورد، بدليل من استخدام فريقكم.
متى لا يستحق الجهد؟ إن كان الفرق بين النظامين واضحًا بعد التقييم، أو كانت المنشأة صغيرة والنطاق قياسيًا، فإثبات المفهوم يؤخر القرار دون أن يغيره. ويستحق الجهد حين يتقارب النظامان، أو يكبر الاستثمار وعدد المستخدمين، أو يبقى معيار حاسم لم يُختبر إلا بالكلام.
تصميم التجربة: ثبّتوا كل شيء إلا النظام
العدالة في إثبات المفهوم لا تأتي من حسن النية، بل من شروط مكتوبة تُرسل للموردين قبل البدء. هذه عناصر التصميم وما يُثبَّت في كل منها:
| العنصر | ما يُثبَّت | لماذا |
|---|---|---|
| السيناريوهات | من خمسة إلى سبعة سيناريوهات من واقعكم، مكتوبة بخطواتها ونتيجتها المتوقعة، تُسلم للموردين معًا | كل مورد يهيئ نظامه للمهام نفسها، لا لما يجيده |
| البيانات | عينة واحدة مجهولة الهوية: عملاء، وجهات اتصال، وفرص مفتوحة ومغلقة، وأنشطة، ومنتجات بأسعارها | البيانات النظيفة النموذجية تخفي مشكلات الاستيراد والبحث والتكرار |
| المستخدمون | المجموعة نفسها تعمل على النظامين: مندوبون، ومشرف، وموظف خدمة، ومسؤول نظام | اختلاف المستخدمين يخلط مهارة الشخص بسهولة النظام |
| المدة | مدة تهيئة متساوية للموردين، ومدة اختبار متساوية للمستخدمين | من يأخذ وقتًا أطول يقدم نظامًا أكثر نضجًا في التجربة لا في الواقع |
| مساعدة المورد | تدريب أولي بالمدة نفسها، ثم الأسئلة عبر قناة مكتوبة واحدة تُسجل | المساعدة الخفية أثناء المهام تجمّل النتيجة، والسجل يكشف جودة الدعم |
| التطوير | يُمنع التطوير البرمجي في التجربة؛ الإعدادات فقط، ويُوثق ما يحتاج تطويرًا | ما يُطوَّر خصيصًا للتجربة لا يعكس النظام الذي ستشترونه |
وحددوا في الخطاب نفسه ما يتعلق بالبيانات: عينة مجهولة الهوية لا بيانات حقيقية حساسة، واتفاقية سرية، والتزام بحذف العينة من بيئة المورد بعد انتهاء التجربة وتأكيد ذلك كتابيًا. واتفقوا مسبقًا على تكلفة التجربة إن وجدت، فبعض الموردين يقدم بيئة تجريبية دون مقابل، وبعضهم يطلب مقابلًا حين تتطلب التهيئة جهدًا كبيرًا. المهم أن تعرفوا ذلك قبل البدء، وأن تكون الشروط متساوية للطرفين.
جدول زمني نموذجي
أربعة أسابيع تكفي عادة لنظامين يعملان بالتوازي. التوازي مهم: إن اختُبر نظام بعد الآخر، سيصل المستخدمون إلى الثاني وقد فهموا المهام، فيبدو أسهل مما هو.
- إعداد السيناريوهات والعينة وخطاب الشروطالأسبوع 1
- تهيئة المورد أ على العينةالأسبوع 2
- تهيئة المورد ب على العينةالأسبوع 2
- تدريب موحد ثم مهام المستخدمين على النظامينالأسبوع 3
- اختبارات المسؤول والتكامل المصغرنهاية الأسبوع 3
- التسجيل والبطاقة النهائية والقرارالأسبوع 4
التناوب في الأسبوع الثالث يعني أن نصف المستخدمين يبدأ بالنظام أ والنصف الآخر بالنظام ب، ثم يتبادلون. بهذا يتوزع أثر «التجربة الثانية أسهل» على النظامين بالتساوي.
ماذا تقيسون، وكيف؟
الانطباع العام بعد التجربة مهم، لكنه يتأثر بمن قدّم التدريب وبأول خمس دقائق. لذلك صمموا لكل معيار دليلًا قابلًا للعد:
- مهام المستخدمين
قائمة من ثماني إلى عشر مهام لكل مستخدم مشتقة من السيناريوهات: تسجيل زيارة ونتيجتها، وتحويل عميل محتمل إلى فرصة، وإصدار عرض بخصم يحتاج اعتمادًا، وفتح تذكرة من محادثة. يُسجل لكل مهمة: هل أُنجزت دون مساعدة، وكم استغرقت، وكم خطأ وقع.
مراقب من لجنة التقييم لكل جلسة - استبيان قصير بعد كل نظام
خمسة أسئلة بمقياس من 1 إلى 5 عن الوضوح والسرعة والثقة في البيانات، وسؤال مفتوح: ما الذي أبطأك؟
المستخدمون - اختبار مسؤول النظام
ثلاثة تعديلات دون مساعدة المورد: إضافة حقل إلزامي في مرحلة معينة، وقاعدة تنبيه عند ركود الفرصة، وتقرير جديد. يُسجل ما أُنجز والوقت، وما احتاج إلى المورد.
مسؤول النظام المرشح لديكم - تكامل مصغر
ليس تكاملًا كاملًا، بل إثبات أن الطريق مفتوح: قراءة قائمة العملاء أو الأسعار من بيئة اختبار لنظامكم المالي، أو استقبال نموذج من الموقع. الهدف أن يرى فريق تقنية المعلومات الواجهة والتوثيق وطريقة المصادقة عمليًا.
تقنية المعلومات - سجل الدعم
كل سؤال أُرسل عبر القناة المكتوبة: وقت الإرسال، ووقت الرد، وهل حل الرد المشكلة.
منسق التجربة
كيف تُكتب مهمة قابلة للقياس؟
المهمة الغامضة مثل «جرّب إدارة الفرص» لا تنتج رقمًا. المهمة القابلة للقياس لها بداية محددة، وبيانات محددة، ونتيجة يمكن التحقق منها في النظام بعد انتهائها. هذا مثال لبطاقة مهمة واحدة:
- السياق: اتصل بك مدير المشتريات في منشأة وهمية من العينة اسمها «مؤسسة النموذج للتشغيل» ويطلب عرضًا لعقد صيانة سنوي لثلاثة مواقع.
- المطلوب: أنشئ فرصة مرتبطة بالعميل وجهة الاتصال الصحيحة، وأضف البنود الثلاثة من الكتالوج، وطبّق خصمًا قدره 12% يتجاوز صلاحيتك، وأرسل العرض للاعتماد.
- النتيجة المتحقق منها: فرصة في المرحلة الصحيحة، وعرض بثلاثة بنود ومجموع صحيح، وطلب اعتماد ظاهر لدى المشرف.
- ما يُسجل: أُنجزت دون مساعدة أم لا، والوقت من فتح النظام إلى إرسال طلب الاعتماد، وعدد المرات التي عاد فيها المستخدم خطوة إلى الوراء.
بطاقة بهذه الدقة تجعل المراقب يسجل وقائع لا آراء، وتسمح بمقارنة النظامين على المهمة نفسها سطرًا بسطر. وتكتب اللجنة نسبة الخصم وحد الصلاحية في السيناريو قبل التهيئة، حتى يُعدّ الموردان مسار الاعتماد نفسه.
وأضيفوا اختبارات دعم العربية إن لم تُحسم في مرحلة سابقة، فالتجربة على بياناتكم أفضل موضع لها، كما تفصّل مقالة كيف تفحص دعم اللغة العربية في CRM. أما توزيع المسؤولية عن كل معيار بين الإدارات وطريقة حل الخلاف بينها فتتناوله مقالة دليل تقييم CRM بمشاركة الإدارات.
من القياس إلى البطاقة النهائية: مثال محسوب
مثال توضيحيشركة خدمات فنية وصلت إلى نظامين نهائيين، وأجرت إثبات مفهوم بثمانية مستخدمين، لكل منهم عشر مهام على كل نظام، أي 80 محاولة على كل نظام. هذه بعض القياسات، وكلها افتراضية لغرض الشرح:
| القياس | النظام أ | النظام ب |
|---|---|---|
| مهام أُنجزت دون مساعدة | 72 من 80 (90%) | 66 من 80 (82.5%) |
| الوقت الوسيط لتسجيل زيارة | دقيقتان ونصف | 4 دقائق |
| تعديلات المسؤول المنجزة دون المورد | 2 من 3 | 3 من 3 |
| التكامل المصغر | لم يكتمل في المدة؛ احتاج توضيحًا من المورد | اكتمل بقراءة الأسعار من بيئة الاختبار |
| سيناريوهات نُفذت كاملة بالإعدادات | 5 من 7 | 7 من 7 |
| اختبار البحث بصيغ الأسماء | ناجح | ناجح جزئيًا |
حوّلت اللجنة القياسات إلى درجات من 0 إلى 4 على سبعة معايير قابلة للاختبار في التجربة، بأوزان حُددت قبل البدء ومجموعها 100: ملاءمة السيناريوهات 25، وسهولة الاستخدام 20، والتكامل 15، والتهيئة بيد المسؤول 10، والتقارير 10، والعربية 10، واستجابة المورد 10.
تفصيل الحساب للنظام أ: 18.75 + 20 + 7.5 + 7.5 + 7.5 + 10 + 7.5 = 78.75. وللنظام ب: 25 + 15 + 11.25 + 10 + 7.5 + 5 + 7.5 = 81.25. الفرق 2.5 نقطة.
كانت اللجنة قد اتفقت قبل التجربة على قاعدة: الفرق الأقل من 5 نقاط تعادل، لا يُحسم بالمجموع. فانتقلت إلى السؤال التالي: أي الضعفين أسهل إغلاقًا وأوضح تكلفة؟ ضعف النظام أ في التكامل ناتج عن تكامل لم يكتمل في المدة، وقد يكون مسألة وقت أو مسألة قيود في الواجهة. وضعف النظام ب في العربية يمس البحث بصيغ الأسماء، وهو في صميم المنصة ويصعب إصلاحه بالإعدادات. طلبت اللجنة من المورد أ جولة إضافية من ثلاثة أيام لإكمال التكامل المصغر، ومن المورد ب التزامًا مكتوبًا بموعد إصلاح البحث مع إثبات على العينة. النتيجة التي تعود من هاتين الجولتين، مع العرض المالي، هي ما يحسم القرار، لا فرق النقطتين ونصف.
أخطاء تفسد نتيجة التجربة
| الخطأ | أثره | العلاج |
|---|---|---|
| تجربة بلا سيناريوهات مكتوبة | كل مستخدم يجرب ما يخطر له، فلا تُقارن النتائج | قائمة مهام موحدة بنتيجة متوقعة لكل مهمة |
| مستخدمون مختلفون لكل نظام | تقارنون أشخاصًا لا أنظمة | المجموعة نفسها على النظامين بالتناوب |
| ممثل المورد يجلس مع المستخدمين | مساعدة غير مسجلة ترفع نسبة الإنجاز | قناة أسئلة مكتوبة فقط أثناء المهام |
| التجربة تتحول إلى تنفيذ مجاني | توسع النطاق وتطول المدة ويتعلق الفريق بنظام قبل القرار | مدة ونطاق مكتوبان، ومنع التطوير البرمجي |
| الاكتفاء بالانطباع | يفوز النظام الأجمل واجهة أو المورد الأفضل تقديمًا | قياسات قابلة للعد لكل معيار |
| تحديد الأوزان بعد النتائج | تُعدل الأوزان لتبرير ميل مسبق | أوزان وقاعدة حسم موقعة قبل البدء |
بعد التجربة: ما الذي تحملونه إلى التعاقد؟
قبل إعلان القرار، اكتبوا مذكرة من صفحة واحدة تحمل: البطاقة النهائية، وقاعدة الحسم التي اتُّفق عليها مسبقًا، ونتيجة الجولة الإضافية إن جرت، والمخاطر المتبقية لدى النظام المختار وطريقة معالجة كل منها. هذه المذكرة تحمي القرار من إعادة فتحه بعد أشهر، حين تُنسى التفاصيل وتبقى الانطباعات.
نتائج إثبات المفهوم ليست للقرار وحده. السيناريوهات التي نُفذت وقياساتها تصبح أساس اختبارات القبول في العقد، فما نجح في التجربة يجب أن ينجح عند الإطلاق بالمعيار نفسه. وما وُعد بإصلاحه في الجولة الإضافية يُكتب في العقد بموعده وطريقة التحقق منه. واحتفظوا بسجل الدعم، فهو مرجع عملي عند التفاوض على مستويات الخدمة.
وإن كان نظامنا أحد النظامين في قائمتكم النهائية، فأرسلوا لنا سيناريوهاتكم وشروط التجربة كما هي. نبدأ بعرض على سيناريو منشأتكم عبر حجز العرض التوضيحي، ثم نتفق على بيئة تجريبية لفريقكم بمدة وسيناريوهات محددة حسب طبيعة المشروع، لتقيسونا بالمعايير نفسها التي تقيسون بها غيرنا. ولمراجعة المقارنات العامة بين أنواع الحلول قبل هذه المرحلة، راجعوا دليل المقارنات والاختيار.
أسئلة شائعة
من ستة إلى عشرة مستخدمين يمثلون الأدوار الرئيسية عادة: مندوبان أو ثلاثة، ومشرف، وموظف خدمة، ومسؤول نظام، وشخص من المالية إن كانت العروض والاعتمادات في النطاق. العدد الأكبر يزيد التنسيق دون أن يضيف دليلًا جديدًا بالقدر نفسه.
استخدموا عينة تحافظ على بنية بياناتكم وأنماطها، مع استبدال الأسماء وأرقام التواصل والمعلومات الحساسة بقيم وهمية. البنية هي ما يكشف مشكلات الاستيراد والبحث، أما البيانات الشخصية الحقيقية فلا حاجة لها في التجربة.
اسألوا عن السبب قبل الحكم. قد يكون الاعتراض على المدة أو التكلفة أو على منع التطوير، وبعضها معقول ويمكن تعديله للطرفين. أما رفض أن يعمل فريقكم على النظام بنفسه، أو رفض قناة الأسئلة المكتوبة، فهو معلومة مهمة عن طريقة عمل المورد بعد التعاقد.
أخبروا كل مورد بنتائجه هو دون نتائج منافسه. هذا يساعده على معالجة ضعف محدد في جولة إضافية إن قررتم ذلك، ويبقي المقارنة سرية وعادلة.