كيف يمكن لمقياس جودة الاختيار تحسين عملية اختيار البرامج فى المؤسسات

اختيار أفضل البرامج الملائمة للمؤسسات

كيف يمكن لمقياس جودة اختيار البرامج تدعيم عملية اختيار البرامج فى المؤسسات؟

الاحتفال بالإنطلاقة الناجحة للبرنامج الجديد فى المؤسسة.

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

أدت عملية شراء البرامج المهمة لأعمال الشركات Business- critical enterprise software إلى إلحاق مخاطر جسيمة بالمنظمات. هذا ويكمن الهدف وراء مشروع الاختيار والتقييم فى شراء البرامج التى تقوم بتعظيم صافى الربح ROI والتقليل من مخاطرعملية التنفيذ، إلا أن الكم الهائل من المتطلبات قد أدى إلى صعوبة تحقيق هذا الأمر. فعلى سبيل المثال، إن الاختيار المتعمق الدقيق لأنظمة إدارة موارد الشركة ERP فى شركة كبيرة يمكن أن تصل متطلباته إلى 10,000 طلب. وهناك أيضًا مشكلة ذكرتها نظرية تأثير دانينغ كروجر Dunnin- Kruger effect وهى المبالغة فى تقدير متخصصى تكنولوجيا المعلومات لقدراتهم على اختيار البرامج والاستخفاف بالجهود المبذولة فى المشاريع.

تحسين عملية اختيار البرامج:

يركز هذا المقال على جزء مهم جدًا فى عملية اقتناء البرامج، ألا وهى عملية التقييم والاختيار مع دراسة كيفية تحسين هذه العملية. وقد تظن أن هذه العملية هى عملية تحسين إجراءات العملBusiness process improvement تركز على اختيار البرامج وتعديلها؛ فرغم مرور المعلومات الناتجة عن التقييمات عبر فِرَق تنفيذ مختصة، إلا أن هذا المقال لا يغطى التطبيق الفعلى للبرنامج.

مقياس جودة اختيار البرامج:

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

لدى مقياس SSMS ستة مستويات مرقمة من 0 إلى 5 كما هو مبين فى الرسم البيانى بالأسفل. وعند تحريك القائمة للأعلى ستجد زيادة فى جودة العمليات بينما تقل مخاطر الشراء. كما يستند كل مستوى على المستوى الأدنى منه.

مقياس جودة اختيار البرنامج

المستوى 0 : لا شئ:

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

المخاطر:

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

المستوى 1_ الأساس الأولى:

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

الخصائص:

• توفر الحد الأدنى من إدارة المشاريع؛ حيث تقوم إدارة المشاريع عادةً بإدارة عملية اختيار المشروع مع القليل من التخطيط لتوفير المصادر اللازمة.
• عدم القدرة على توضيح الاحتياجات التنظيمية؛ فالمتطلبات قد تم تحديدها على مستندات Word وجداول بيانات وهو تحديدًا ضعيفًا فى حد ذاته.
• يتم تقييم البرامج تقييمًا بسيطًا تجاه هذه المتطلبات. وإذا استُخدِمَ البرنامج يكون تسجيل النقاط أوليًا.
• يكون اختيار البرنامج شخصى، ويمكن اختياره من قبل لجنة. كما قد يعتمد اختيار البرنامج أيضًا على خبرات سابقة مثل "أعرف ما أقوم به" ( أنظر تأثير دونينغ كروجر) مع دراسة صغيرة للفروق التنظيمية.

المخاطر:

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

المستوى 2_ القاعدة الأساسية:

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

الخصائص:

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

المخاطر:

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

المستوى 3_ التعريف:

تُنشأ عمليتىْ اختيار البرنامج وتقييمه، ثم اتباعها وإدارتها.

الخصائص:

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

المخاطر:

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

المستوى 4_ التحقق والتعديل:

يتم التحقق من مطالبات البائعين وتعديل نطاق المشروع إذا لم يتطابق مع ما يقدمه السوق.

الخصائص:

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

المخاطر:

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

المستوى 5_ التحسين والاختبار والتعديل:

تدار مخاطر اقتناء البرامج وتقليلها؛ حيث يُعَدّل عقد الشراء لمشاركة المخاطر مع البائع. كما يتحقق الاختبار من مستوى آداء أعمال البرنامج. مع إجراء التحسينات اللازمة على عملية الشراء.

الخصائص:

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

الخاتمة:

استخدم مقياس SSMS لقياس جودة عملية اختيار برنامجك الخاص. لاحظ إنه يمكن لمختلف المشاريع العمل فى عدة مواضع فى هذا المقياس. حيث يمكن لمنظمة ما على سبيل المثال تعمل فى المستوى 3 تعيين نائب رئيس جديد يقوم بشراء منتج برنامج معين لقى استحسانه، دون النظر فى البدائل. هذا المشروع فى يعمل فى المستوى 0.

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

وأخيرًا، تساعد جودة عملية اختيار البرامج المنظمات على مقابلة صافى الربح المستخدم فى تسوية شراء البرنامج، بل وتخطى ROI.

كريس دويغ Chris Doig