الخلاصة أولاً
البناء المخصص منطقي حين يكون النظام ميزة تنافسية لا أداة تشغيل. إن كان ما تريده هو إدارة مشاريعك ومخططاتك ومستخلصاتك — وهي احتياجات يتشاركها كل مكتب هندسي — فأنت تبني ما بُني آلاف المرات، وتتحمّل وحدك كلفة صيانته إلى الأبد.
لماذا تبدو الفكرة جذابة؟
وهي جذابة لأسباب حقيقية لا وهمية:
- مطابقة تامة لسير عملك — بلا تنازلات ولا تطويع
- لا اشتراك شهري — تكلفة تُدفع مرة وتنتهي، ظاهرياً
- ملكية كاملة — النظام لك ولا تعتمد على مزوّد
- مرونة التغيير — تعدّل ما تشاء متى شئت
كل نقطة من هذه صحيحة في السنة الأولى. والمشكلة تبدأ في الثانية.
ما الذي يُنسى في الحساب؟
تقدير تكلفة البناء يشمل عادةً التحليل والتطوير والاختبار. وهذه أقل من نصف التكلفة الحقيقية:
| البند | يُحسب عادةً؟ | لماذا يهم |
|---|---|---|
| تحليل المتطلبات والتصميم | نعم | — |
| التطوير والاختبار | نعم | — |
| إصلاح الأخطاء بعد الإطلاق | نادراً | كل نظام جديد يحتاج أشهراً حتى يستقر |
| التطوير عند تغيّر سير العمل | لا | مكتبك يتغير — والنظام يجب أن يتبعه |
| تحديثات الأمن والبنية | لا | مكتبات وأطر عمل تتقادم وتصبح ثغرات |
| الاستضافة والنسخ الاحتياطي | جزئياً | بند شهري دائم |
| وقت فريقك في التحليل والاختبار | لا | أشهر من وقت مهندسيك ومديرك |
| كلفة التأخير | لا | أشهر التطوير هي أشهر استمرار المشكلة |
| استمرارية المعرفة | لا | من يفهم الكود إن غادر من كتبه؟ |
البند الأخطر
استمرارية المعرفة. النظام الجاهز تصونه شركة لها فريق وعمليات واستمرارية. والنظام المخصص يصونه غالباً مطوّر واحد أو شركة صغيرة — ومغادرته تحوّل نظامك إلى صندوق أسود لا أحد يجرؤ على تعديله. هذه ليست حالة نادرة بل النتيجة الأشيع بعد ثلاث سنوات.
أربع مخاطر بنيوية في البناء المخصص
مخاطرة النطاق
المتطلبات تتضخم أثناء التطوير — كل قسم يريد إضافة. المشروع الذي قُدّر بستة أشهر يصبح خمسة عشر، والميزانية تتبعه.
مخاطرة التبنّي
النظام المبني داخلياً لا يمر بتجربة مئات المكاتب. واجهته وسير عمله يعكسان رأي من طلبه لا ممارسة القطاع — فيصعب على الفريق استخدامه.
مخاطرة الصيانة
لا فريق منتج يصلح الأخطاء ويحدّث الأمن. كل خلل يصبح مشروعاً صغيراً، وكل ثغرة أمنية مسؤوليتك وحدك.
مخاطرة التقادم
النظام الجاهز يتطور مع القطاع — فوترة إلكترونية جديدة، متطلب تنظيمي، ممارسة مستجدة. والنظام المخصص يتقادم ما لم تموّل تطويره باستمرار.
متى يكون البناء المخصص قراراً صحيحاً؟
نقولها صراحةً — في ثلاث حالات، وهي أضيق مما يُظن:
- حين يكون النظام ميزتك التنافسية نفسها. إن كان ما تبنيه هو ما يميّزك في السوق — منهجية حسابية فريدة، أو خدمة رقمية تبيعها لعملائك — فهو منتج لا أداة، ويستحق الاستثمار.
- حين يكون لديك فريق تطوير داخلي قائم. ليس مطوّراً واحداً بل فريقاً بعمليات واستمرارية. عندها تتحول التكلفة المتكررة من فاتورة خارجية إلى استخدام لقدرة تملكها.
- حين يكون الاحتياج فريداً فعلاً. اختبرها بصدق: اعرض متطلباتك على ثلاثة أنظمة جاهزة. إن غطّى أحدها 80% منها، فأنت تبني مقابل الـ20% الباقية — وهي غالباً أرخص بالتطويع من البناء الكامل.
اختبار الثمانين بالمئة
معظم المكاتب التي قررت البناء لم تفعل ذلك لأن الأنظمة الجاهزة لا تكفيها، بل لأنها لم تقيّمها بجدية. جرّب ثلاثة أنظمة بقائمة متطلبات مكتوبة قبل أن تقرر البناء — الجهد يوم واحد، والقرار يمتد سنوات.
اختبر الثمانين بالمئة قبل أن تبني
احجز جلسة نعرض فيها كيف يغطي النظام الجاهز متطلباتك — بلا التزام. إن اتضح أن احتياجك فريد فعلاً، فستكون قد حسمت السؤال بدل تخمينه.
احجز عرضاً قبل قرار التطويرالخيار الثالث الذي يُغفل
السؤال ليس ثنائياً دائماً. هناك مسار وسط يختاره كثيرون:
- نظام جاهز للأساس — المشاريع والمخططات والمستخلصات والمالية
- تطوير مخصص للفريد فقط — الجزء الذي يميّز مكتبك حقاً
- ربط بينهما عبر واجهة برمجية
هذا يعطيك الاستقرار والصيانة المدعومة في الأساس، والتخصيص حيث يستحق فعلاً — بدل بناء كل شيء من الصفر ثم صيانة كل شيء إلى الأبد.
إطار القرار في أربعة أسئلة
| السؤال | إن كانت الإجابة «لا» |
|---|---|
| هل النظام ميزتنا التنافسية لا أداة تشغيل؟ | رجّح الشراء |
| هل لدينا فريق تطوير داخلي مستمر؟ | رجّح الشراء بقوة |
| هل قيّمنا ثلاثة أنظمة جاهزة بقائمة مكتوبة؟ | قيّمها أولاً ثم قرّر |
| هل حسبنا التكلفة على خمس سنوات لا سنة؟ | أعد الحساب قبل القرار |