كيفية تقييم البرامج قبل اعتمادها وتجنب الفشل في المحاولة

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

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

لماذا من المفيد تقييم البرامج بدقة؟

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

يساعد التقييم الدقيق على:تقليل الذاتية في عملية اتخاذ القرار، يتم استبدال الآراء غير الدقيقة بمعايير واضحة وقابلة للقياس.

كما يسمح مواءمة التكنولوجيا مع الاستراتيجيةالهدف ليس "امتلاك أحدث الأدوات"، بل حل مشاكل محددة، وتحسين العمليات، وإضافة قيمة إلى العمل أو المؤسسة (سواء كانت شركة أو جامعة أو مركزًا تعليميًا).

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

الخطوة الأولى: فهم ما تحتاجه حقًا

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

حدد الأشخاص الرئيسيين المعنيين

أول شيء هو أن يكون واضحاً من هم المتضررون من المشروع؟ وما هي قوة ومصلحة كل جهة معنية. ومن الطرق المفيدة لتحقيق ذلك تطوير مصفوفة لأصحاب المصلحة تميز بين:

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

يساعد هذا التصنيف على تخطيط الاتصالات وإدارة التغييرهذا أمر أساسي لضمان عدم عرقلة اعتماد البرمجيات بسبب المقاومة الداخلية.

حدد رؤية المشروع والقيمة التي يسعى إلى تحقيقها

من الممارسات الجيدة استخدام "لوحة رؤية المنتج" أو مخطط مشابه يجيب على أسئلة مثل:ما هو الغرض من هذا البرنامج؟ (ما هو التغيير الإيجابي المرغوب فيه).

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

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

قم بتحليل الوضع والعمليات الحالية

لا يكفي أن نقول "نحن بحاجة إلى نظام جديد"؛ يجب علينا لفهم ما يحدث اليوم بالتفصيل:

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

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

كيفية توثيق المتطلبات دون إغفال أي شيء

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

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

تتضمن المصفوفة عادةً، لكل متطلب:مُعرِّف، وصف، غرض، تصنيف (إلزامي أو مرغوب فيه) والمنطقة التي تطلبه.

عليك أن تميز بين:المتطلبات الوظيفية (ما يجب أن يفعله النظام: العمليات، الشاشات، التقارير، التدفقات، قواعد العمل).

Y المتطلبات غير الوظيفية أو معايير الجودةوالتي تؤثر على كيفية عمل البرنامج، مثل:

• أمن: ضوابط الوصول، والمصادقة (اسم المستخدم/كلمة المرور، والشهادات، والبيانات البيومترية...)، وتشفير البيانات، وحماية قواعد البيانات، وتتبع المعاملات، والبروتوكولات الآمنة (HTTPS، وSSL، وSFTP...).
• الأداء وقدرة التحميل: أقصى وقت استجابة، وعدد المستخدمين المتزامنين، وحجم المعاملات، واختبره باستخدام .
• كفاءة الموارداستهلاك وحدة المعالجة المركزية، واستخدام ذاكرة الوصول العشوائي، واستخدام الشبكة، والتأثير على البنية التحتية.
• قابلية التشغيل البيني والتكامل: الحاجة إلى الاتصال بأنظمة أخرى، وتبادل البيانات في الوقت الفعلي أو على دفعات، واستخدام واجهات برمجة التطبيقات والمعايير.
• التوافق: المتصفحات وأنظمة التشغيل وأنواع الأجهزة المدعومة (الهواتف المحمولة والأجهزة اللوحية وأجهزة الكمبيوتر المكتبية).
• دقةنسبة التوافر، تحمل الأعطال، القدرة على الاسترداد في حالة السقوط أو الكوارث.
• سهولة الاستخدام وسهولة الوصول: سهولة الاستخدام، وقت التعلم، التصميم البديهي، دعم المستخدمين ذوي الإعاقة (قارئات الشاشة، التباين، أحجام الخطوط، لوحة المفاتيح، المساعدة السياقية ...).
• قابلية الصيانة: نمطية الكود، وسهولة تطبيق التغييرات، وإمكانية التدقيق، وسياسات التحديث.
• قابلية: إمكانية نقل النظام إلى منصات أخرى أو إلى السحابة مع الحد الأدنى من التعديلات.
• الجوانب القانونية والتنظيمية: حماية البيانات الشخصية، والامتثال للوائح الداخلية أو القطاعية، وتراخيص الأطراف الثالثة.
• الاختبار، وإصلاح الأخطاء، والتطوير: كيف سيتم اختبار الإصدارات الجديدة، والتعامل مع الحوادث، وإدارة الإصدارات.
• الدعم والضمان: ما هو مستوى الدعم المتوقع من الموفر، وأوقات الاستجابة، والقنوات، وتغطية الأخطاء.

المفتاح هو لا تترك هذه النقاط دون حل.لأنهم هم من يصنعون الفرق بين نظام "يعمل نظرياً" ونظام يصمد أمام واقع الحياة اليومية.

تصنيف المتطلبات الإلزامية والمستحبة

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

الكثير مرغوب فيه أو اختياري هذه ميزات تضيف قيمة ولكن يمكن تأجيلها إلى مرحلة ثانية أو التضحية بها إذا كانت تعقد عملية التبني بشكل كبير.

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

قم بتقييم أهمية كل مجموعة من المتطلبات

بمجرد تحديدها والتحقق من صحتها، يصبح من المفيد تعيينها الأوزان المخصصة للفئات المختلفة (على سبيل المثال، الوظائف، والأمان، والتكلفة، وسهولة الاستخدام، والتكامل) بحيث لا يقتصر تقييم البدائل على "الإعجاب/عدم الإعجاب".

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

بدائل لدمج البرامج: الأمر لا يقتصر على شراء التراخيص فقط.

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

الخيار الأول: اعتماد البرامج الموجودة في مؤسستك

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

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

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

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

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

في كلتا الحالتين، من الضروري التفاوض على شروط الاستخدام والدعم وسرية البيانات والتعديلات المحتملةبالإضافة إلى الاتفاق على فترة تجريبية في بيئة خاضعة للرقابة (30 أو 60 أو 90 يومًا) للتحقق من النسبة المئوية لمصفوفة المتطلبات التي يتم تغطيتها.

الخيار الثاني: البرامج الخارجية كخدمة (SaaS)

إذا لم يكن هناك حل داخلي مناسب، فإن البديل الشائع جدًا هو الاشتراك في خدمة SaaS سحابيةدفع رسوم شهرية أو سنوية لكل مستخدم، أو لكل حجم، أو لكل استخدام.

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

لتقييم برنامج SaaS، عليك مراعاة ما يلي:

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

يُنصح بالاعتماد على معايير اقتناء البرمجيات (مثل ممارسات IEEE 41062) لتنظيم العملية وعدم ترك أي تفاصيل مهمة غير مكتملة خارج العقد.

الخيار الثالث: الحصول على حلول برمجية تجارية أو مفتوحة المصدر

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

في هذا السيناريو، من الضروري تحليل، من بين جوانب أخرى:

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

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

الخيار الرابع: تعزيز أو نقل نظام مخصص موجود

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

يحدث هذا عادة لسببين:التغييرات في عمليات الأعمال أو اللوائح أو الاحتياجات الوظيفية والتي تتطلب توسيع النظام أو تعديله.

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

في هذه الحالات، يُنصح بتقييم ما يلي:

• تأثير التغييرات: ما إذا كانت بعض التعديلات كافية أم أن جزءًا كبيرًا من الحل يحتاج إلى إعادة التفكير.
• تكلفة ومخاطر الانتقال التكنولوجي (على سبيل المثال، من إصدار قديم من PHP أو .NET إلى إصدار حديث) باستخدام الأدوات الآلية كلما أمكن ذلك.
• إمكانية نقل البيانات والتوافق مع الأنظمة الأخرى والتي يتكامل معها البرنامج.
• التخطيط للتحديثات الدورية حتى لا "نعلق" مرة أخرى مع الإصدارات القديمة التي يصعب صيانتها.

من المهم أيضًا دمج التحسينات الأمنية (للتخفيف من مخاطر سرقة المعلومات أو سرقة الهوية أو الأضرار الاقتصادية) الاستفادة من فرصة التحديث.

الخيار الخامس: تطوير برامج مخصصة بالكامل

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

يوفر هذا المسار أقصى قدر من المرونة، ولكنه يوفر أيضًا عادة ما يكون هو الأغلى والأبطأويتطلب ذلك مستوى عالٍ من النضج التنظيمي والتقني.

لتحقيق النجاح في هذا الأمر، عليك القيام بما يلي:

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

في حال اختيار التعاقد من الباطن، تدخل معايير إضافية حيز التنفيذ، مثل:خبرة المورد السابقة، ومهارات فريقه، ومعايير الجودة، وحقوق الملكية الفكرية للبرنامج، والضمانات، والتدريب، ونقل المعرفة.

قم بتقييم ومقارنة البدائل بموضوعية

بعد تحديد الخيارات (سواء كانت داخلية أو تجارية أو برمجيات كخدمة أو تطويرات)، فقد حان الوقت لـ ضع الأرقام على الجدولوهنا تظهر فائدة مصفوفة المتطلبات والوزن المسبق.

التقييم يعتمد على مدى الالتزام بالمتطلبات

يتم إجراء تقييم لكل بديل. ما هو مستوى الامتثال الذي تتمتع به فيما يتعلق بكل متطلب؟ من المصفوفة. يمكن استخدام مقاييس بسيطة (على سبيل المثال، من 0 إلى 5) حيث يعني 0 عدم الامتثال وتشير القيمة القصوى إلى الامتثال الكامل.

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

تحليل التكلفة والعائد

إلى جانب الملاءمة الوظيفية، من الضروري إجراء تحليل التكلفة والفائدة يتضمن:

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

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

ملخص تنفيذي لاتخاذ القرار

بعد إعداد النتائج والتحليل الاقتصادي، يُنصح بإعداد ملخص تنفيذي موجه للإدارة هذا ما يلفت الانتباه:

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

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

جرّب البرنامج قبل الشراء: عروض توضيحية، ونسخ تجريبية، وبيئات اختبارية.

يُعد جزءًا أساسيًا من عملية التقييم اختبر البرنامج في ظل أكثر الظروف واقعية الممكنةقبل توقيع أي التزامات طويلة الأمد.

عروض تقديمية مخصصة وإثباتات للمفهوم

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

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

بيئات تجريبية آمنة للتجربة بدون مخاطر

يُتيح العديد من الموردين خدمة التجميع بيئات تجريبية مناطق معزولة حيث يمكن لفرقك تجربة البرنامج دون التأثير على البيانات الحقيقية أو الإنتاج.

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

في المؤسسات ذات الاحتياجات المتقدمة (على سبيل المثال، التكامل مع خدمات سحابية مثل AWS أو Azure، أو أتمتة العمليات، أو استخدام الذكاء الاصطناعي)، تساعد بيئة الاختبار المصممة جيدًا على تقييم الجدوى التقنية قبل إطلاق عملية النشر واسعة النطاق.

ورش عمل لتقييم ما بعد العرض التوضيحي وتقديم الملاحظات

بعد العروض التوضيحية والتجارب الأولية، من الجيد تنظيم ورش عمل التقييم مع أصحاب المصلحة الرئيسيين لجمع تعليقات منظمة، وليس مجرد تعليقات عشوائية من الممر.

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

• المزايا ونقاط القوة المتصورة من البرنامج.
• القيود أو المشاكل أو المخاطر التي تم رصدها.
• توصيات للتحسين أو التعديل والتي يمكن للمزود معالجتها.

يُساهم هذا التقرير في التقييم الكمي ويساعد على تحسين المفاوضات مع المورد أو القرار النهائي.

اختبار القبول: دع للمستخدمين الكلمة الأخيرة

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

اختبار قبول المستخدم (UAT)

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

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

أنواع أخرى من اختبارات القبول

بالإضافة إلى اختبارات قبول المستخدم التقليدية، يمكن تطبيق ما يلي:

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

هدفهم المشترك هو تقليل مخاطر نشر نظام لا يلبي التوقعات بمجرد تشغيله. أو التسبب في حوادث خطيرة.

التدقيق الفني النافي للجهالة: تقييم التكنولوجيا في المعاملات التجارية

عندما يتم اعتماد البرمجيات كجزء من استثمار، أو استحواذ على شركة، أو اندماجوهنا يأتي دور العناية الفنية الواجبة، وهي نوع من "الفحص الفني لتكنولوجيا المعلومات" لتجنب المفاجآت غير السارة.

ما الذي ينظر إليه المستثمرون حقاً؟

في عملية التدقيق الفني، يسعى المستثمرون أو المشترون إلى فهم ما إذا كانت تقنية الشركة:

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

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

أخطاء شائعة عند الاستعداد لإجراءات التدقيق النافي للجهالة

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

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

ومن الشائع أيضا المبالغة في استخدام الذكاء الاصطناعي بدون بنية بيانات قوية تدعمها، مما يولد عدم ثقة بين المقيمين.

دور الذكاء الاصطناعي وإدارة البيانات

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

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

أول 100 يوم بعد الاستحواذ

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

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

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