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

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

وهو يفترض أنك قرّرت بالفعل شراء نظام جاهز. فإن كنت ما تزال تفاضل بين نظام جاهز ونظام يُبنى لك خصيصًا، ابدأ بمقال كيف تُتّخذ القرار بين أودو ونظام مخصّص ثم عُد إلى هنا.

الخطوة الأولى: دوّن ما يجب أن يفعله البرنامج، قبل أن يُريك أحد أي شيء

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

لذا دوّن القائمة أوّلًا، انطلاقًا من طريقة عمل نشاطك فعلًا.

• اعبر عملياتك الفعلية خطوة بخطوة. من الطلب إلى التسليم، ومن الشراء إلى السداد، ومن أمر الإنتاج إلى التعبئة، وإقفال نهاية الشهر. ودوّن مَن يفعل ماذا وأين يتعثّر الأمر اليوم.
• حوّلها إلى سيناريوهات. من عشر إلى عشرين حالة ملموسة، مكتوبة كقصص: «يطلب عميل 300 قطعة بثلاثة مقاسات، ويسدّد نصف القيمة مقدَّمًا، ثم يغيّر لون أحد المقاسات بعد بدء القص». وأدرِج حالاتك الصعبة لا الاعتيادية فقط.
• صنّف كل متطلَّب. طريقة بسيطة أن تُعنون كل متطلَّب بأنه ضروري (must have) أو مهم (should have) أو مرغوب (could have) أو مؤجَّل (will not have) هذه المرة. وكن صارمًا مع العنوان الأول: فالمتطلَّب الضروري هو ما لا تشتري بدونه إطلاقًا.

الخطوة الثانية: حوّل السيناريوهات إلى نص عرض توضيحي

أرسل السيناريوهات نفسها إلى كل مورّد، مسبقًا، واطلب منه أن يعرضها — بالترتيب نفسه، وببيانات تشبه بياناتك — بدل عرضه القياسي. والمورّد الذي لا يستطيع فعل هذا أو لا يريده يكون قد أخبرك بشيء مهم.

وفي كل عرض توضيحي، يتابع شخص واحد النص ويسجّل، عن كل سيناريو، واحدة من أربع نتائج:

• يعمل قياسيًا.
• يعمل بالتهيئة — إعدادات، بلا برمجة.
• يحتاج تطويرًا — على أحد أن يكتب شيفرة. ودوّن مَن، ومدة الأمر، ومَن يصونه عبر الترقيات.
• لا يمكن تنفيذه.

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

الخطوة الثالثة: قيّمها على ورقة مرجّحة

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

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

أما لصفوف الجودة، فالمرجع الدولي هو نموذج ISO/IEC 25010 لجودة منتجات البرمجيات. وتقسّم نسخته الحالية الجودة إلى خصائص مثل الملاءمة الوظيفية، وكفاءة الأداء، والتوافقية، وقدرة التفاعل (وهي ما كانت النسخ السابقة تسميه سهولة الاستخدام)، والموثوقية، والأمن، وقابلية الصيانة، والمرونة، والسلامة. ولست مضطرًا لاستخدام المعيار رسميًا، لكن مراجعة قائمته وسيلة جيدة لالتقاط معيار نسيته.

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

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

الخطوة الرابعة: دع المستخدمين الفعليين يجرّبونه

يقدّم العرض التوضيحي خبير على بيانات مُعدّة سلفًا. أمّا مَن سيستخدمون النظام يوميًا فليسوا خبراء، وبياناتك ليست مُعدّة سلفًا.

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

الخطوة الخامسة: تحدّث إلى عملاء لم يختَرهم المورّد لك

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

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

والإجابة الأخيرة أقلّ أهمية من التردّد الذي يسبقها.

الفخاخ

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

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

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

المصادر

• ISO/IEC 25010: the product quality model — بوابة ISO 25000. خصائص الجودة المستخدمة كقائمة مراجعة أعلاه.
• Digital Outcomes and Specialists buyers' guide — الحكومة البريطانية. تقييم الموردين بالسيناريوهات ودراسات الحالة والمراجع، بنظام تقييم واحد وأوزان متفق عليها.
• Evaluation stage — الوظيفة التجارية بالحكومة البريطانية. تقييم العروض وفق معايير محددة وتسجيل سبب كل درجة.