برمجيات مخصّصة أم حل جاهز (SaaS)؟

ترى Mesterséges Intelligencia Központ Kft.، شركة تطوير البرمجيات في بودابست بالمجر، أن البرنامج الجاهز (SaaS) يكفي إذا غطّى العمليات، وأن البرنامج المخصّص يستحق العناء إذا اختلفت طريقة العمل عن المعتاد، أو كان البرنامج نفسه هو الميزة التجارية.

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

ماذا تعني البرمجيات المخصّصة والبرمجيات الجاهزة وSaaS؟

تجيب هذه المفاهيم الثلاثة عن سؤالين مختلفين: الأول هو لمن صُنع البرنامج، والثاني هو كيف يصل إلى المستخدم.

البرمجيات المخصّصة: برنامج يُطوَّر بالطلب لتلبية احتياجات شركة بعينها. يؤدي ما طلبه العميل في المواصفات، بالطريقة التي يعمل بها موظفوه، والعميل هو من يقرر أيضًا اتجاه التطوير اللاحق.
البرمجيات الجاهزة (المعلّبة): منتج يُصنع لعملاء كثيرين، تحصل الشركة على ترخيص لاستخدامه، وتثبّته وتشغّله عادةً على أجهزتها أو خادمها. ويمكن تكييفه عبر الإعدادات، لكن منطق عمله يحدده المورِّد.
SaaS (Software as a Service، أي البرمجيات كخدمة): برنامج جاهز يشغّله المورِّد في سحابته الخاصة، وتستخدمه الشركة بالاشتراك، من المتصفح أو عبر واجهة برمجية. والواجهة البرمجية (API، application programming interface) هي نقطة الاتصال التي يتبادل عبرها برنامجان البيانات دون تدخّل بشري.

بحسب تعريف الحوسبة السحابية الصادر عن المعهد الوطني الأمريكي للمعايير والتقنية (NIST)، يستخدم المستخدم في حالة SaaS تطبيق مزوّد الخدمة الذي يعمل في السحابة، ولا يدير البنية التحتية التي تقف خلفه (الشبكة، والخوادم، ونظام التشغيل، والتخزين)، بل ولا حتى وظائف التطبيق المنفردة، باستثناء إعدادات محدودة على مستوى المستخدم (NIST SP 800-145). وهذه هي قوة SaaS وحدّها في آن واحد: فالمورِّد يرفع عبء التشغيل عن كاهل الشركة، لكنه هو أيضًا من يقرر ما الذي يتغير في المنتج، ومتى.

الطريق الثالث: أساس جاهز مع إضافات مخصّصة

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

التكامل: برنامج مخصّص يربط الأنظمة الجاهزة عبر API أو webhook، فلا تعود هناك حاجة إلى نسخ البيانات يدويًا. والـwebhook إشعار آلي يرسله نظام إلى نظام آخر عند وقوع حدث ما، مثل وصول طلب جديد.
وحدة مخصّصة: يُبنى إلى جانب النظام الجاهز تطبيق خاص للعملية التي لا يغطيها المنتج الجاهز، مثل قاعدة تسعير خاصة، أو جدولة الإنتاج، أو سجل خاص بقطاع معيّن.
واجهة خاصة فوق النظام الجاهز: يحصل العملاء أو الموظفون العاملون في الميدان على واجهة بسيطة مفصّلة على مقاس مهمتهم، بينما يعمل النظام الجاهز في الخلفية.

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

معايير القرار في جدول واحد

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

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

علامَ تتوقف التكلفة الإجمالية للملكية؟

التكلفة الإجمالية للملكية (بالإنجليزية total cost of ownership، واختصارًا TCO) هي النفقات الموزّعة على مدة استخدام البرنامج كاملة، لا سعر البدء فحسب. ويختلف هيكل التكلفة في الطريقين، ولذلك قد تكون مقارنة سنة واحدة مضلّلة: فمن المفيد النظر إلى مدة الاستخدام المخطط لها.

في البرمجيات الجاهزة وSaaS تتشكّل التكلفة عادةً من:

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

وفي البرمجيات المخصّصة:

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

يمكن التخطيط لتكلفة التطوير المخصّص إذا قيس النطاق بدلًا من تقديره بالحدس. فنحن نقيس الحجم الوظيفي للتطوير بنقاط COSMIC الوظيفية (ISO/IEC 19761)، ومنه يُعَدّ العرض والجدول الزمني؛ وتصف صفحة التسعير الطريقة. أما أيّ الطريقين أقل تكلفة على المدى الطويل، فذلك يتوقف على عدد المستخدمين، ووتيرة التغييرات، وعدد التكاملات. ولا جواب عامًا عن ذلك، بل حساب يُعَدّ للحالة المحددة.

الارتهان للمورِّد وقابلية نقل البيانات

نتحدث عن الارتهان للمورِّد (بالإنجليزية vendor lock-in) عندما يكون التبديل إلى منتج آخر صعبًا أو مكلفًا إلى حد يجعل الشركة عاجزة عمليًا عن الخروج. وقد يكون سببه صيغة بيانات مغلقة، أو تصديرًا ناقصًا، أو كثرة الإعدادات المرتبطة بهذا المنتج وحده، أو عقدًا يصعب إنهاؤه.

يُطبَّق قانون البيانات في الاتحاد الأوروبي (Data Act، اللائحة (EU) 2023/2854) منذ 12 سبتمبر 2025، وينظّم في فصل مستقل التبديل بين خدمات معالجة البيانات؛ وتُدرج ديباجته SaaS أيضًا ضمن هذه الخدمات. وينص نص اللائحة على أمور منها (تم التحقق في 17 أكتوبر 2026):

يجب تحديد شروط التبديل في عقد مكتوب، ولا يجوز أن تتجاوز مهلة الإشعار اللازمة لبدء التبديل شهرين (المادة 25).
يجب إتاحة التبديل عند الطلب، دون تأخير غير مبرَّر، خلال فترة انتقالية لا تتجاوز 30 يومًا تقويميًا، يجب أن تستمر الخدمة في العمل خلالها؛ وإذا تعذّر ذلك تقنيًا، يجوز لمزوّد الخدمة، مع التعليل، أن يحدد فترة انتقالية لا تتجاوز سبعة أشهر (المادة 25).
يجب أن يسرد العقد البيانات القابلة للنقل بندًا بندًا، وأن يتيح فترة لا تقل عن 30 يومًا تقويميًا لاسترجاع البيانات (المادة 25).
اعتبارًا من 12 يناير 2027 لا يجوز لمزوّد الخدمة أن يتقاضى رسومًا مقابل عملية التبديل؛ وحتى ذلك الحين لا يجوز له إلا تقاضي رسوم مخفّضة لا تتجاوز تكاليفه المرتبطة بالتبديل ارتباطًا مباشرًا (المادة 29).

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

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

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

لمن تعود الشيفرة المصدرية؟

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

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

تختلف الموازنة باختلاف نوع النظام

المعايير المذكورة أعلاه عامة، لكن وزنها يختلف من نوع نظام إلى آخر. ففي نظام تخطيط موارد المؤسسة تكون العلاقة بين التخصيص وقابلية الترقية هي المسألة الحاسمة، ونكتب عن ذلك في مقال نظام ERP مخصّص أم نظام ERP جاهز بعد تخصيصه؟. وفي نظام إدارة العملاء تكتسب عملية المبيعات الخاصة والترخيص لكل مستخدم أهمية كبيرة؛ انظروا مقال متى يستحق تطوير نظام CRM مخصّص العناء؟. وفي المتجر الإلكتروني تتقابل سرعة إطلاق المنصات المستأجَرة مع حرية التوسيع (انظروا مقال المتجر الإلكتروني: منصة مستأجَرة أم تطوير مخصّص؟). ويمكنكم القراءة عن تطوير أنظمة الأعمال عمومًا في صفحة برمجيات الأعمال.

قائمة التحقق للقرار

الإجابات عن الأسئلة التالية تحدد الطريق من تلقاء نفسها في أغلب الأحيان:

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

الأخطاء المعتادة

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

الأسئلة الشائعة

متى يستحق تطوير برنامج مخصّص العناء؟

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

هل البرمجيات المخصّصة أعلى تكلفة على المدى الطويل؟

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

ماذا يحدث لبياناتنا إذا ألغينا اشتراك SaaS؟

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

هل يمكن الجمع بين الاثنين؟

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

لمن ستكون الشيفرة المصدرية؟

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

كيف نساعدكم؟

تطوّر Mesterséges Intelligencia Központ Kft. البرمجيات المخصّصة، وتربط الأنظمة الجاهزة، وبالذكاء الاصطناعي أيضًا حيث يوفّر عملًا حقيقيًا: فنحن نربط النماذج اللغوية من OpenAI (ChatGPT) وAnthropic (Claude) وGoogle (Gemini) بالأنظمة القائمة. الاستشارة الأولى مجانية، وسنقول لكم فيها أيضًا إن كان منتج جاهز يكفي. وإذا لزم التطوير المخصّص، نقيس حجمه الوظيفي بنقاط COSMIC الوظيفية، ومنه يُعَدّ العرض والجدول الزمني. ونوقّع عند الطلب اتفاقية عدم إفصاح (NDA)، وبعد التسليم نتولى التشغيل والصيانة أيضًا. وتخضع الشيفرة المصدرية وحقوق الاستخدام لأحكام العقد.

التفاصيل في صفحة تطوير البرمجيات المخصّصة. وإن أردتم التحدث معنا عن وضعكم، فاكتبوا لنا عبر بيانات التواصل الواردة في صفحة التواصل.