بناء البرمجيات أم شراؤها: متى يستحق النظام المخصص تكلفته؟

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

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

ابدأ بالعملية قبل البرنامج

قبل مقارنة المورّدين أو تقدير جهد التطوير، صنّف العملية التي سيخدمها النظام.

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

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

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

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

احسب التكلفة على مدى ثلاث إلى خمس سنوات

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

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

وهناك ثلاث نقاط يكثر التهاون في تقديرها.

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

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

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

التكامل وملكية البيانات

قيمة أي نظام مرهونة بقدرته على الاتصال بالأنظمة المحيطة به. تحقّق من النقاط التالية أيًّا كان الخيار:

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

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

النهج الهجين: اشترِ الأساس وابنِ الأطراف

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

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

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

أسئلة تُطرح قبل القرار

خذوا هذه الأسئلة إلى اجتماع اتخاذ القرار:

1. هل هذه العملية مصدر ميزة لنا، أم أمر يكفي أن نؤديه بكفاءة؟
2. هل شاهدنا عرضًا عمليًا لمنتجين على الأقل وفق حالاتنا الفعلية، لا وفق العرض المعدّ سلفًا من المورّد؟
3. ما نسبة متطلباتنا التي يلبّيها أفضل منتج دون تخصيص؟ وهل الفجوات المتبقية ضرورية أم مجرد عادات عمل؟
4. هل تغيير عمليتنا لتوافق المنتج مقبول، وربما أفضل؟
5. كم يكلّف كل خيار خلال خمس سنوات، شاملًا الكوادر والتغييرات؟
6. من سيملك هذا النظام داخل المنشأة بعد إطلاقه؟
7. كيف نخرج من هذا الخيار إن ثبت خطؤه، وكم يكلّف ذلك؟
8. هل نملك القدرة التقنية على صيانة نظام مخصص لسنوات، أو نستطيع التعاقد عليها بصورة موثوقة؟

إذا تعذّرت الإجابة عن السؤال السادس فالأولى تأجيل القرار. فالنظام الذي لا مالك له سيخيّب التوقعات، سواء اشتُري أم بُني.

متى يصح كل خيار

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

ابنِ إذا كانت العملية تميّزكم، والمنتجات المتاحة تفرض تنازلات مضرّة، وتحتاجون إلى التحكم في البيانات وخطة التطوير، وتستطيعون الالتزام بملكية النظام على المدى الطويل.

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

الخلاصة العملية

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

وإذا كنتم تدرسون نظامًا بعينه وتودّون الاستئناس برأي آخر، فيسعد فريق تقنية مناقشة الأمر معكم.