اختر نظامًا جاهزًا عندما ينجز العمليات الأساسية لشركتك بإعدادات مقبولة وتكلفة تشغيل واضحة. وادرس النظام المخصص عندما تبقى فجوات جوهرية بعد تجربة الحلول المتاحة، ويمكنك تحديدها وتمويل تطويرها وصيانتها. وقد يكفي ربط نظام قائم بواجهة أو وحدة مخصصة بدل استبداله كاملًا.
القرار العملي لا يبدأ بسؤال «أيهما أفضل؟»، بل بثلاثة أسئلة: هل ينجز العمل المطلوب؟ هل تستطيع تشغيله وتغييره؟ وهل تعرف تكلفة استخدامه والخروج منه؟ هذا الدليل يقدم ورقة تقييم تستطيع استخدامها مع فريقك والموردين، دون افتراض أن الخيار الأغلى أو الأكثر تخصيصًا هو الأنسب.
فرّق بين الشراء والتهيئة والتطوير
النظام الجاهز منتج موجود تشتري حق استخدامه وفق عرضه وشروطه. وقد يكون اشتراكًا سحابيًا أو برنامجًا يُشغّل في بيئة أخرى؛ كلمة SaaS تصف طريقة تقديم الخدمة، وليست اسمًا لكل برنامج جاهز.
التهيئة تعني استخدام الإعدادات التي يوفرها المنتج، مثل إضافة أنواع طلبات أو تعديل أدوار. أما التخصيص فقد يشمل برمجة إضافة أو تغييرًا في المنتج. والنظام المخصص يُبنى وفق نطاق متفق عليه، مع احتمال استخدام مكونات جاهزة داخله. لذلك اطلب من المورد تحديد معنى «يدعم التخصيص» في عرضه: إعداد متاح، أم تطوير إضافي، أم مجرد احتمال يحتاج دراسة؟
تعرض إرشادات استراتيجية الشراء لدى GOV.UK البناء والشراء والجمع بينهما، وتوصي بتجربة عملية عند تقييم المنتج. نستخدمها هنا كمرجع لمنهج الشراء، لا كقواعد ملزمة لشركات السعودية أو الخليج.
ضع شروطًا لا يعوّض غيابها مجموع النقاط
قبل ترتيب العروض، حدد ما يمنع اعتماد أي خيار. اجعل كل شرط قابلًا للفحص، لا وصفًا مثل «آمن ومرن»:
| شرط أساسي | الدليل الذي تطلبه |
|---|---|
| رحلة العمل الضرورية | تنفيذها ببيانات تجريبية تمثل الحالة المطلوبة |
| صلاحيات مناسبة | تجربة مستخدم مسموح وآخر ممنوع من الإجراء نفسه |
| وصول مقبول إلى البيانات | عينة تصدير مفهومة تشمل الحقول والعلاقات اللازمة |
| تشغيل ومسؤولية واضحان | تحديد من يعالج الأعطال والتحديثات والنسخ والاستعادة |
| قيود المؤسسة | مراجعة متطلبات الاستضافة والخصوصية والتعاقد المعتمدة لديكم |
إذا فشل خيار في شرط أساسي، فإما أن يقدم معالجة محددة يمكن التحقق منها، أو يخرج من القائمة. لا تجعل سعرًا أقل أو عشرات المزايا الثانوية تعوّض غياب وظيفة لا يمكن تشغيل العمل دونها. وفي المقابل، لا تحوّل كل تفضيل إلى شرط استبعاد؛ اسأل صاحب العملية عمّا يتوقف العمل فعلًا بغيابه.
جرّب هذا السيناريو بدل مشاهدة عرض مبيعات فقط
لنفترض أن الشركة تقارن حلولًا لطلبات شراء داخلية. هذا تمرين افتراضي، وليس وصفًا لعميل أو نتيجة تنفيذ لدى PIXELSAA. أعطِ كل مورد البيانات التجريبية نفسها، واطلب تنفيذ التسلسل التالي:
- موظف يرسل طلبًا يحتوي بندين ومرفقًا.
- المراجع يرفض بندًا ويطلب تعديل الآخر مع حفظ السبب.
- الموظف يصحح الطلب دون أن يستطيع اعتماد طلبه بنفسه.
- ينتقل الاعتماد إلى بديل عند غياب المسؤول وفق قاعدة متفق عليها.
- يستخرج المدير تقريرًا ثم يصدر الطلبات وأسباب القرارات بصيغة قابلة للاستخدام.
سجل أين اكتملت الرحلة، وأين احتاجت إجراءً خارج النظام. اسأل عن تكلفة سد الفجوة وتأثير التعديل في التحديثات القادمة. لا تسجل وعدًا شفهيًا على أنه وظيفة اجتازت التجربة.
في النظام الذي لم يُبنَ بعد، يمكن اختبار الجزء الأكثر غموضًا بنموذج وظيفي محدود وطلب خطة للمخاطر الباقية. نجاح النموذج لا يثبت جاهزية النظام الكامل، لكنه أفضل من افتراض أن كل وظيفة مقترحة أصبحت متاحة.
ورقة ترجيح تساعد على النقاش
بعد اجتياز الشروط الأساسية، استخدم الأوزان الآتية كنقطة بداية تحريرية؛ ليست معيارًا معتمدًا أو نتيجة قياس. عدّلها قبل مشاهدة العروض بحسب أولويات شركتك.
| محور التقييم | وزن مقترح | ما يُكتب بجوار الدرجة |
|---|---|---|
| ملاءمة رحلة العمل | 30 | الحالات التي نجحت والفجوات |
| التكامل والبيانات | 20 | تجربة الاتصال والتصدير |
| تكلفة الملكية | 20 | البنود والافتراضات ضمن مدة واحدة |
| سهولة التشغيل والدعم | 15 | مسؤول التشغيل وخطة التعامل مع العطل |
| قابلية التغيير والانتقال | 15 | الاعتماد على المورد وخطة التسليم أو الخروج |
استخدم درجات من 0 إلى 3: 0 لا يحقق المعيار، 1 يحتاج معالجة يدوية مؤثرة، 2 يحققه مع عمل إضافي موصوف، 3 يحققه ضمن النطاق المقارن وبالدليل المناسب. إذا لم تتوفر معلومات، اكتب «غير محسوم» وأجّل ترتيب الخيار بدل ملء الفراغ بدرجة متفائلة.
يمكن حساب مؤشر الترتيب بجمع الوزن × الدرجة ÷ 3 لكل محور. يصل الحد الأعلى إلى 100 لأن الأوزان مجموعها 100؛ هذا رقم لتنظيم المقارنة، وليس نسبة نجاح متوقعة أو عائدًا ماليًا. لا توجد هنا عتبة نجاح عامة. وإذا كان ترتيب خيارين يتبدل عند تغيير بسيط في الأوزان، فراجع الافتراض الحاسم بدل التعامل مع فارق النقاط كحقيقة نهائية.
قارن تكلفة الملكية على المدة نفسها
لا تقارن فاتورة تطوير واحدة باشتراك شهر واحد. اختر مدة تناسب قرارك، مثل 24 شهرًا كمثال تخطيطي، واطلب البنود التالية لكل بديل:
| البند | جاهز أو مهيأ | مخصص أو مدمج |
|---|---|---|
| البداية | تهيئة وتدريب وترحيل | تحليل وبناء واختبار وترحيل |
| الاستخدام | تراخيص وحسابات وإضافات | استضافة وخدمات وتراخيص مستخدمة |
| التغيير | إعدادات أو إضافات وتحديثها | تطوير تغييرات واختبارها |
| التشغيل | الدعم المتعاقد عليه ومسؤوليات الفريق | الصيانة والدعم ومسؤوليات الفريق |
| التكامل | رسوم الوصول والربط إن وجدت | بناء الاتصال وتشغيله إن لزم |
| نهاية العلاقة | تصدير ومساعدة انتقال وفق الشروط | تسليم واعتماديات وانتقال وفق الاتفاق |
اترك المبلغ فارغًا إلى أن يأتي من عرض أو تعرفة موثقة. ميّز أيضًا بين مصروف نقدي تدفعه وبين وقت داخلي تقدره. إذا احتسبت ساعات موظفيك ماليًا، أظهر عدد الساعات ومعدل التقييم كافتراض؛ لا تضف رقمًا باسم «خسائر العمل اليدوي» دون طريقة حساب.
لا تفترض أن النظام المخصص بلا مصاريف مستمرة، أو أن الجاهز أرخص دائمًا على المدى الطويل. اطلب سيناريو استخدام حاليًا وآخر يختلف في عدد المستخدمين أو حجم البيانات، دون تحويل خطة النمو إلى توقع مؤكد.
من يتحمل العمل بعد توقيع العقد؟
الأمان ليس صفة مضمونة بكلمتي «جاهز» أو «مخصص». ففي نموذج AWS، تتوزع مسؤوليات الأمان بين المزود والعميل، ويختلف التقسيم بحسب الخدمة المستخدمة. هذا مثال يوضح ضرورة تحديد المسؤوليات، لا وصفًا تلقائيًا لعقد كل مورد SaaS. نموذج المسؤولية المشتركة لدى AWS.
اسأل في كلا الخيارين: من يضيف المستخدمين ويغلق حساباتهم؟ من يراجع صلاحيات التصدير؟ من يجرب الاستعادة؟ ومن يقرر موعد التحديث؟ واطلب توضيح ما تتسلمه من بيانات وشيفرة ووثائق وحسابات بحسب الاتفاق؛ لا تفترض أن دفع تكلفة تطوير ينقل تلقائيًا كل الحقوق أو الاعتماديات.
إذا لم يوجد داخل الشركة شخص يملك قرارات العملية، فاحسم هذه المسؤولية قبل توسيع المشروع. المورد يستطيع تنفيذ قرار موثق، لكنه لا يستطيع حل خلاف دائم بين الإدارات بمجرد إضافة شاشة.
متى يرجح كل مسار؟
- ابدأ بمنتج جاهز إذا اجتازت رحلة العمل التجربة، وكانت التهيئة والتكلفة وشروط التشغيل مقبولة.
- أضف وحدة أو تكاملًا محدودًا إذا كان النظام الحالي يؤدي معظم العمل، وكانت الفجوة واضحة ويمكن وصلها دون تكرار بيانات غير منضبط.
- ادرس البناء المخصص إذا بقيت فجوة أساسية موثقة ولم توفر الخيارات المجربة معالجة مناسبة، وكان نطاق التنفيذ والتشغيل قابلًا للتمويل والإدارة.
- أجّل قرار التنفيذ إذا كانت القواعد أو البيانات نفسها غير محسومة؛ ابدأ بتحليل أو تجربة محدودة لها سؤال واضح ومخرج يمكن مراجعته.
يعرض نظام مبيعات كروت الشبكات في أعمال PIXELSAA مثالًا موثقًا يجمع المبيعات والمخزون والعملاء والتحصيل والتقارير وسجل النشاط. هذه وظائف تساعد على صياغة سيناريو تقييم، وليست دليلًا على أن شركتك تحتاج النسخة نفسها أو أن منتجًا جاهزًا رُفض في هذا المشروع.
إذا اتجه القرار إلى البناء، استخدم دليل تكلفة تطوير نظام مخصص لتحويل المتطلبات إلى ميزانية وبنود قبول. ويشرح دليل أنظمة Laravel للشركات أسئلة التنفيذ والتقنية. ولخطوتك الحالية، جهّز قائمة بالشروط الأساسية والفجوات التي ظهرت في التجربة، ثم راجع خدمة تطوير الأنظمة المخصصة وناقش الخيارات المناسبة مع PIXELSAA. الهدف من المحادثة تحديد ما يستحق البناء وما يمكن إبقاؤه أو تهيئته.
