بناء نظام داخلي لمنشأتك: قرارات تقنية تحدد تكلفته لسنوات

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

السؤال الأول: هل تحتاج أن تبني أصلاً؟

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

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

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

اختيار التقنيات: الشائع أفضل من الذكي

لا تحتاج الإدارة أن تختار لغة البرمجة، لكنها تحتاج أن تطرح سؤالاً واحداً: هل سنجد بسهولة من يعمل على هذا النظام بعد خمس سنوات؟

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

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

من يملك الكود والحسابات؟

هذا أكثر بند يُهمَل في العقود، وأكثرها كلفة عند الخلاف. تأكد أن العقد والواقع يتفقان على ما يلي:

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

المنشأة التي لا تملك حساب الاستضافة لا تملك نظامها فعلياً، مهما قال العقد.

التوثيق والتسليم: اختبار «لو غاب غداً»

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

• وصفاً لبنية النظام ومكوناته وأين يعمل كل مكون
• خطوات تشغيله من الصفر على بيئة جديدة
• قائمة بالخدمات الخارجية التي يعتمد عليها وتكلفة كل منها
• جلسة تسليم مسجلة مع الفريق الذي سيتولى التشغيل

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

الاختبار والنشر الآلي: ما الذي يعنيه للإدارة؟

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

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

تكلفة ما بعد الإطلاق

احسب الميزانية على عمر النظام، لا على مدة المشروع. البنود التي تتكرر بعد الإطلاق:

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

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

تجنّب الاعتماد على شخص واحد

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

• لا أحد غيره يعرف كيف يُنشر تعديل جديد
• الحسابات الأساسية مرتبطة ببريده أو رقم جواله الشخصي
• كل سؤال عن النظام ينتهي بـ«اسأله هو»

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

الخلاصة

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